So che ci sono molte domande come questa su AskDifferent, ma non ne ho trovato nessuno che risolva in modo specifico l'omissione evidente nelle più moderne versioni di Mac OS per la crittografia della cartella home per utente tramite FileFault.
Non so quando Apple l'abbia cambiato, ma le versioni precedenti di OS X FileVault consentono di crittografare le intere cartelle utente / utente / [utente]. Non solo era "possibile", aveva un'interfaccia estremamente semplice che sembrava incoraggiare gli utenti a scoprire la funzionalità, e farlo.
Ad esempio, ho un Macbook Pro 6,2 2010 che esegue Snow Leopard, con cartelle crittografate / Utenti / [utente]. È una funzionalità eccezionale e molto necessaria per molti casi d'uso. (Ad esempio, la maggior parte degli scenari in cui più utenti usano lo stesso macbook, a casa o al lavoro.) Non aggiornerò mai il sistema operativo, in modo da non perdere questa funzionalità!
Uso anche un Macbook Pro 11,3 del 2014 che esegue El Capitan. FileVault non ha questa opzione per crittografare / Utenti / [utente]. Questo sembra un enorme passo indietro. La crittografia dell'intero disco, sebbene sia importante se si perde il laptop mentre è completamente spento, non farà nulla per risolvere il caso di uso comune sopra menzionato. (Inoltre, alcuni esperti considerano di avere cartelle home cifrate - più un account "ospite" senza password [più un servizio di recupero in esecuzione] - un buon modo per migliorare le probabilità di recuperare la macchina. Non perfetto e nessuna corrispondenza per ladri professionisti che solo puliscilo comunque, ma meglio di niente.)
Quindi questa domanda è in realtà divisa in due parti: 1) Esiste una soluzione, idealmente nativa, per la crittografia per utente / utenti / [utente]; e 2) Perché Apple ha rimosso una funzionalità così essenziale da FileVault? Forse solo Apple lo sa. Ma spesso il "perché" delle decisioni controverse è pubblicamente noto o almeno conosciuto. Per esempio. spiegati nei blog degli sviluppatori, note di rilascio, video di conferenze di utenti / sviluppatori pubblici, discorsi di convegni, interviste di sviluppatori di blog tecnologici, ecc.
Sono pienamente consapevole che è banalmente facile creare un file di loopback crittografato che posso montare dopo l'accesso e persino automatizzare il montaggio di, per archiviare documenti sensibili. Ma come sappiamo, c'è un bel po 'di potenziale sensibile le informazioni che vengono memorizzate automaticamente in / User / [home], in base alla progettazione e come previsto da Apple, incluse le impostazioni di cui potremmo non essere a conoscenza, che rendono imperativa la crittografia per utente dell'intero / utenti / [utente]. (E inoltre, invece di usare un file di loopback crittografato, userò semplicemente una cartella eCryptFS condivisa via SMB su una VM con Linux, che è la mia soluzione standard su Windows e Mac quando non eseguo Linux in modo nativo.)
BTW - Non uso TimeMachine.
Aggiornamento : il motivo fondamentale per la crittografia per utente della cartella / utente / [utente], con chiavi di crittografia univoche, è per proteggere i dati degli utenti da altri utenti della stessa sistema . Mentre uno potrebbe non essere d'accordo nel dare a più utenti gli stessi diritti sudo del sistema, ci sono molti casi legittimi di utilizzo per farlo. FileVault2 si limita a "proteggere" gli utenti gli uni dagli altri, tramite autorizzazioni file unix. Ma l'accesso ai dati degli altri è solo un "sudo chmod -R". Questa non è una soluzione reale , al fine di proteggere i dati degli utenti l'uno dall'altro. Una soluzione reale prevede chiavi di crittografia univoche delle intere cartelle domestiche dell'utente (/ home / [utente] o / utenti / [utente]). Molte distribuzioni Linux rendono questo banalmente facile, così come le versioni precedenti di Mac OS X / FileVault.
Aggiornamento 2 : le cartelle di sistema come Library e var "potrebbero" contenere dati utente sensibili, memorizzate apposta da app negligentemente progettate o trapelate accidentalmente, ma 1) quasi mai nel mondo reale di i sistemi unix e unix-like, 2) per convenzione per applicazioni ben educate non dovrebbero, e 3) soprattutto - non sono nemmeno fisicamente in grado di aumentare l'età della sandbox - es. Mac OS non consente alle app in esecuzione in modalità utente di scrivere in posizioni sensibili come quella. Inoltre, solo perché applicazioni mal comportate e / o dannose potrebbero perdere dati utente sensibili in una cartella di sistema, non è un argomento razionale contro un utente o un requisito organizzativo per proteggere gli utenti sudo gli uni contro gli altri sullo stesso sistema. Ma piuttosto che aggiungere un dibattito inutile a questa domanda, aggiorniamo semplicemente il requisito:
"Proteggere i dati degli utenti l'uno con l'altro con le proprie chiavi di crittografia univoche applicate all'intera cartella Utente / Utente / [utente], indipendentemente dal fatto che tutti gli utenti abbiano o meno diritti sudo, al fine di proteggere tutti i loro normali dati in modalità utente, ad eccezione del caso intrinsecamente difficile da coprire dei dati sensibili degli utenti trasmessi alle cartelle di sistema globali che, naturalmente, si suppone siano impossibili a livello di sistema operativo quando le app in modalità sandbox vengono eseguite dall'utente normale modalità ".