Zombie Physicist
Poster original- 22 mai 2014
- 31 ianuarie 2021
Cu toate acestea, acum, dacă formatați pentru prima dată o unitate ca APFS Encrypted și încercați să utilizați Big Sur (cel mai recent 11.1 și anterior 11.01) pe acea unitate, veți primi următoarea eroare:
„Nu puteți instala pe acest volum, deoarece are o parolă de disc”
Cu toate acestea, dacă instalați pe o unitate necriptată, mai târziu puteți selecta FileVault și întregul container va fi criptat conform acestui fir: https://discussions.apple.com/thread/252036326
Cu toate acestea, aceasta înseamnă că oricine poate pur și simplu să răsucească comutatorul FileVault și să anuleze criptarea de pe unitate. Acest lucru este rău atunci când nu doriți ca unitatea să fie necriptată în niciun moment.
Întrebarea este DE CE!? De ce acest comportament. Lucrul curent este să instalați Catalina pe o unitate criptată APFS și apoi să faceți un upgrade pe acea unitate. Big Sur funcționează și funcționează bine, dar de ce ai nevoie de munca nebună?
Mi-ar plăcea orice gânduri/speculații despre dacă aceasta este o eroare sau o caracteristică și dacă este o caracteristică, DE CE!?
robotică
- 10 iulie 2007
- Edinburgh
- 31 ianuarie 2021
svanstrom
la
- 8 februarie 2002
- 🇸🇪
- 31 ianuarie 2021
Cum afectează macOS Big Sur (11.0) criptarea volumului în Endpoint Security pentru Mac
A sustine
www.bitdefender.com Probleme cunoscute macOS Big Sur | Carbon Copy Cloner | Software Bombich
bombich.comZombie Physicist
Poster original- 22 mai 2014
- 31 ianuarie 2021
robotica a spus: S-ar putea să fi fost o modificare a protocolului de criptare? Ar putea dori să folosească criptarea sa actualizată.
Am folosit atât formatarea APFS mai veche și am încercat unități proaspăt formatate cu 11.1. Deci folosesc propria sa criptare.
Totuși, presupunerea ta este una bună, deoarece ceva profund s-a schimbat între criptarea unității pe 11.01 și 11.1 în ceea ce privește modul în care Big Sur face backup-urile mașinii timpului. Vezi acest subiect: https://forums.macrumors.com/threads/best-way-to-format-time-machine-drive.2280154/
A fost o diferență de performanță zi și noapte, reformatarea în APFS în 11.1 și re-run time machine.
Oricum, aici, chiar și atunci când reformatez cu 11.1, tot nu mă lasă să instalez sistemul de operare.
Zombie Physicist
Poster original- 22 mai 2014
- 31 ianuarie 2021
svanstrom a spus: Ok, deci o căutare rapidă pare să-mi spună că au fost făcute modificări la CoreStorage...
Cum afectează macOS Big Sur (11.0) criptarea volumului în Endpoint Security pentru Mac
A sustinewww.bitdefender.com
Probleme cunoscute macOS Big Sur | Carbon Copy Cloner | Software Bombich
bombich.com
Da, nu mă îndoiesc că s-au schimbat multe lucruri, dar totuși funcționează dacă faci un format complet de unitate criptat APFS, instalezi Catalina și apoi faci upgrade-ul Big Sur. Deși poate fi o diferență fără o diferență prin aceea că mă întreb dacă nu a făcut o „conversie”.
Înseamnă că văd că FileVault-ul meu este pornit și că containerul de unitate arată ca APFS Encrypted pe unitate în Disk Utility.app... Mă întreb dacă doar dezactivez FileVault pe computer dacă, în esență, va dezactiva criptarea APFS cu acel comutator acum? Cu toate acestea, panoul de securitate afișează o cheie de recuperare... Nu știu dacă doar pornirea/dezactivarea fileVault-ului dvs. vanilla setează o cheie de recuperare? Ultima modificare: 31 ianuarie 2021 C
Chilipp
- 19 februarie 2021
- 19 februarie 2021
Pentru mine, se pare că este cauzat de noua politică a Apple: „nu criptați containerul de sistem, deoarece este montat numai în citire și conține aceleași date pentru toate mac-urile de acolo”. Poate că „Apple crede” că ar putea fi, de asemenea, o îmbunătățire a energiei și a performanței generale, deoarece nicio criptare nu are ca rezultat un consum mai mic de energie și „performanță”.
Nu știu, dar anunțați-mă dacă găsiți o soluție pentru instalarea Big Sur pe un volum APFS proaspăt și deja criptat.
Zombie Physicist
Poster original- 22 mai 2014
- 20 februarie 2021
De ce bănuiesc asta. Pentru că tocmai am instalat Big Sur fresh pe o unitate APFS necriptată. Pune peste 10 TB de date într-un cont. APOI a activat seiful de fișiere și întregul lucru a fost „criptat” în mai puțin de un minut, iar acum containerul se afișează ca un container criptat APFS. NICIO MOD a procesat atât de multe date atât de repede, așa că înseamnă că aceste lucruri sunt întotdeauna criptate de la început. Deci, dacă este așa, de ce să nu mă lăsați să blochez oricum întreaga unitate, pentru că argumentul privind performanța/consumul de criptare dispare dacă totul este în esență întotdeauna criptat oricum.
Pentru mine, ceea ce înseamnă cu adevărat este că întreaga unitate a fost ÎNTOTDEAUNA criptată și acum i-am setat o cheie. Dar asta mă face super îngrijorată. Asta înseamnă că Filevault funcționează cu 2 chei? Și cu sistemul de operare capabil să schimbe ușor accesul prin parolă. Cum a fost aceasta criptată până acum? Aș putea să înțeleg lucrurile greșit, dar acest lucru aduce în evidență spectrul unei chei universale de deblocare/uși din spate.
Daverich4
- 13 ianuarie 2020
- 20 februarie 2021
ZombiePhysicist a spus: Cu toate acestea, aceasta înseamnă că oricine poate pur și simplu să răsucească comutatorul FileVault și să anuleze criptarea de pe unitate. Acest lucru este rău atunci când nu doriți ca unitatea să fie necriptată în niciun moment.Aveți nevoie de numele și parola de administrator pentru a dezactiva FileVault. Cum este diferit de orice altă formă de criptare?
Cârlatani
- 18 septembrie 2013
- Manchester, Marea Britanie
- 20 februarie 2021
diskutil apfs list iar rezultatul nu arată totuși nicio criptare pentru toate volumele
atât pentru Macintosh HD, cât și pentru Macintosh HD - Volumele de date pe care le arată
criptat - Nu (criptat în repaus) C
Chilipp
- 19 februarie 2021
- 21 februarie 2021
Daverich4 a spus: Aveți nevoie de numele și parola de administrator pentru a dezactiva FileVault. Cum este diferit de orice altă formă de criptare?Diferența este că, în cazul meu, parola mea de criptare a discului diferă întotdeauna de parola conturilor mele de utilizator și eu personal nu o stochez/conectez cu brelocul din cauza problemelor de securitate.
ZombiePhysicist a spus: Aș putea să înțeleg lucrurile greșit, dar acest lucru scoate în evidență spectrul unei chei universale de deblocare/uși din spate.
Sunt total de acord cu tine - nici nu-mi place faptul că primim doar un fel de „cheie de recuperare” care poate nu este cheia de criptare folosită efectiv - așa că nu am idee ce cheie (sau abaterea cheii-aleatorie -algoritm) este folosit pentru criptare. J
jcscol
- 26 septembrie 2018
- 21 februarie 2021
ZombiePhysicist a spus: Tocmai am instalat Big Sur fresh pe o unitate APFS necriptată. Pune peste 10 TB de date într-un cont. APOI a activat seiful de fișiere și întregul lucru a fost „criptat” în mai puțin de un minut, iar acum containerul se afișează ca un container criptat APFS. NIMIC să proceseze atât de multe date atât de repedeAceasta nu a fost experiența mea când am pornit Filevault în Big Sur la instalarea mea originală sau pe clonele de pornire CCC. Ei trec prin procesul de criptare, cu o unitate de 300 GB care durează peste o oră pe macbook-ul meu.
Pentru mine, ceea ce înseamnă cu adevărat este că întreaga unitate a fost ÎNTOTDEAUNA criptată și acum i-am setat o cheie.Nu am văzut niciun indiciu că acesta este cazul aici
dar acest lucru scoate în evidență spectrul unei chei universale de deblocare/uși din spate.Doar dacă presupunerea ta este corectă, ceea ce nu cred că este. D
Daverich4
- 13 ianuarie 2020
- 21 februarie 2021
Chilipp a spus: Diferența este că, în cazul meu, parola mea de criptare a discului diferă întotdeauna de parola conturilor mele de utilizator și eu personal nu o stochez/conectez cu brelocul din cauza problemelor de securitate.Cred că nu înțeleg ceva aici. Discuția a fost despre dezactivarea FileVault, ceva care necesită acces la un computer deblocat. În acel moment, accesul la unitatea criptată este transparent, nu este necesară o parolă. Vorbesti despre altceva? C
Chilipp
- 19 februarie 2021
- 21 februarie 2021
Daverich4 a spus: Cred că nu înțeleg ceva aici. Discuția a fost despre dezactivarea FileVault, ceva care necesită acces la un computer deblocat. În acel moment, accesul la unitatea criptată este transparent, nu este necesară o parolă. Vorbesti despre altceva?
În ceea ce mă privește, discuția este despre incapacitatea de a instala Big Sur pe un volum criptat anterior/în avans.
Și chiar dacă cineva poate dezactiva fișierul seif doar pentru un computer deja deblocat, cu siguranță face o diferență dacă este posibil să-l dezactivezi deloc sau nu.
Dacă cineva, de exemplu, smulge parola contului meu, ar fi posibil să dezactivez total criptarea. Ca rezultat, datele mele (potențiale) sensibile sunt copiate necriptate pe volum și ar fi mai ușor pentru cineva să-și „recupereze” conținutul chiar dacă criptarea este activată din nou (dacă nu este suprascrisă).
Deci, din punct de vedere al securității, acest lucru este interzis pentru datele sensibile, de asemenea, pe HDD și SSD. J
jcscol
- 26 septembrie 2018
- 21 februarie 2021
Chilipp a spus: În ceea ce mă privește, discuția este despre incapacitatea de a instala Big Sur pe un volum criptat anterior/în avans.BINE ...
Dacă cineva, de exemplu, smulge parola contului meu, ar fi posibil să dezactivez total criptarea. Ca rezultat, datele mele (potențiale) sensibile sunt copiate necriptate pe volum și ar fi mai ușor pentru cineva să-și „recupereze” conținutul chiar dacă criptarea este activată din nou (dacă nu este suprascrisă).
Doar până la finalizarea procesului de re-criptare, dar totuși...
Luând scenariul cuiva:
a) Cine are acces la aparatul dvs
b) Cunoaște parola contului dvs. de administrator
Având discul de pornire criptat separat, nu vă va oferi nicio protecție suplimentară în acest scenariu *cu excepția cazului în care* mașina este oprită (deoarece unitatea criptată separat a fost deja deblocată pentru ca sistemul să poată porni).
Deci, din punct de vedere al securității, acest lucru este interzis pentru datele sensibile, de asemenea, pe HDD și SSD.
Oricum, nu ar trebui să vă bazați pe Filevault pentru protejarea datelor super-sensibile. Astfel de date sensibile ar trebui să fie stocate într-un fișier imagine rară criptat separat (cu o parolă diferită) pe unitatea Filevault.
Zombie Physicist
Poster original- 22 mai 2014
- 21 februarie 2021
jcscol a spus: Aceasta nu a fost experiența mea când am pornit Filevault în Big Sur la instalarea mea originală sau pe clonele de pornire CCC. Ei trec prin procesul de criptare, cu o unitate de 300 GB care durează peste o oră pe macbook-ul meu.
Nu am văzut niciun indiciu că acesta este cazul aici
Doar dacă presupunerea ta este corectă, ceea ce nu cred că este.
Încercați-l la o instalare nouă. Iti spun. Se întâmplă în decurs de un minut sau 2. criptarea NIMIC este de fapt finalizată atât de repede. O face pe măsură ce merge. Nu am altă explicație pentru criptarea aproape instantanee a unui întreg volum plin de date (mai mulți terabytes).
Tocmai am făcut asta cu o instalare nouă 11.2.1 pe o unitate non-T2, iar pornirea FileVault a fost făcută într-un minut sau 2. Acesta a fost pe un Mac Pro cu 28 de nuclee destul de puternic, dar nu am văzut suficientă utilizare a discului iStat pentru a garantează senzația că trece prin toate datele. Nu destul de aproape. Poate că este diferit când lucrezi la o clonă cumva?
S-ar putea să existe un alt tip de criptare cu mai multe chei pe care nu le înțeleg. Nu sunt un expert în criptare, nu este deloc în timonerie.
Acestea fiind spuse, știu suficient că mai mulți teraocteți nu sunt criptați în 2 minute. Un gând ar fi dacă acest lucru s-ar întâmpla pe o unitate T2. Bine, acesta este întotdeauna criptat. Dar aceasta este pe unitatea mea PCI Micron 9300 Pro U.2. Sistemul de operare îl vede ca pe o unitate externă, nu primește tratamentul T2.
O explicație este că face o criptare constantă din mers chiar și pe unități „necriptate” și există o anumită gestionare a cheilor pe care nu le înțeleg. Dar mi-aș dori ca procesul să nu fie atât de opac. Ultima modificare: 21 februarie 2021
Posturi Populare