New sovereign controls for GCP via Assured Workloads | Google Cloud Blog
https://cloud.google.com/blog/products/identity-security/new-sovereign-contr... (Sent from my wireless device; please excuse brevity and typos (if any))
On 07/10/21 18:10, J.C. DE MARTIN wrote:
https://cloud.google.com/blog/products/identity-security/new-sovereign-contr...
Mi sa un po' di presa per i fondelli o sbaglio? Innanzi tutto la cifratura è a riposo, per cui quando una applicazione usa un dato, esso finisce in chiaro in RAM. Inoltre ci sono sempre i metadati completamente a disposizione del provider. Puro marketing claim... Non possono pensare seriamente che la genta si beva 'sta roba... D.
On October 7, 2021 4:22:20 PM UTC, "D. Davide Lamanna" wrote:
On 07/10/21 18:10, J.C. DE MARTIN wrote:
https://cloud.google.com/blog/products/identity-security/new-sovereign-contr...
Mi sa un po' di presa per i fondelli o sbaglio?
No, è politica. In Google possono tranquillamente spendere milioni di dollari per tirar su un'infrastruttura di sicurezza inefficace solo per poter dare qualcosa ai propri lobbisti su cui lavorare a Bruxelles.
Innanzi tutto la cifratura è a riposo, per cui quando una applicazione usa un dato, esso finisce in chiaro in RAM.
Esatto. E chiunque abbia accesso alla macchina che esegue tale applicazione può accedere al dato.
Inoltre ci sono sempre i metadati completamente a disposizione del provider.
Oh ma anche i dati: a quanto ho potuto capire dalla documentazione (piuttosto vaga, per gli standard di Google) niente impedisce tecnicamente a Google (o al Governo USA) di salvarsi le chiavi AES ottenute dal keymanager esterno per decifrare comodamente i dati successivamente. Letteralmente niente. In effetti, le KAJ servono a GIUSTIFICARE l'accesso ma non necessariamente a descriverne l'intera finalità. La copia dei dati non lascia tracce. E le chiavi crittografiche SONO dati.
Puro marketing claim... Non possono pensare seriamente che la genta si beva 'sta roba...
Io credo invece che siano piuttosto confidenti: il marketing è il loro pane. D'altro canto l'articolo è firmato da due product manager, non da ingegneri o crittografi che abbiano una credibilità da mantenere. Purtroppo in tanti faranno finta di crederci. Eppure una notizia c'è: Google ammette di temere l'autonomia cibernetica Europea. Giacomo
Ciao Giacomo, Giacomo Tesio <giacomo@tesio.it> writes: [...]
Innanzi tutto la cifratura è a riposo, per cui quando una applicazione usa un dato, esso finisce in chiaro in RAM.
Esatto. E chiunque abbia accesso alla macchina che esegue tale applicazione può accedere al dato.
approfitto a man bassa della tua disponibilità per esercitare ancora una volta il mio /snobbismo/ nei confronti delle campagne di markeing e di crypto-washing di certe multinazionali e ti faccio una domanda secca: quindi le chiavi private sono fornite alle macchine remote e la decrittazione avviene su quelle (perché i processi che consumano i dati girano lì)? [...]
Eppure una notizia c'è: Google ammette di temere l'autonomia cibernetica Europea.
Mavà, quandomai?!? :-D [...] Ciao, 380° -- 380° (Giovanni Biscuolo public alter ego) «Noi, incompetenti come siamo, non abbiamo alcun titolo per suggerire alcunché» Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about <https://stallmansupport.org>.
Ciao Giovanni, On Fri, 08 Oct 2021 12:33:37 +0200 380° wrote:
quindi le chiavi private sono fornite alle macchine remote e la decrittazione avviene su quelle (perché i processi che consumano i dati girano lì)?
No, a quanto posso capire leggendo varie fonti [1][2][3][4][5] la decrittazione avviene sulle macchine di Google. Sulle macchine di "terze parti europee fidate" vengono solo mantenute le chiavi di cifratura (credo di aver letto AES 256) e Google fa giurin giuretto che non se le copia su una USB fra un utilizzo e l'altro. E che non le lascia copiare (quasi) a nessun altro senza dirtelo. Dal "white paper" [4]:
we will never use it for any purpose other than those necessary to fulfill our contractual/legal obligations. [...]
Access Approval (Beta) requires Google administrators to seek explicit customer approval before Google can access data or configurations, except in rare legal and outage use cases ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Infatti, se rileggi attentamente l'articolo condiviso da Juan Carlos, noterai un linguaggio molto attento a lasciare intendere che le chiavi non sono accessibili a Google senza mentire spudoratamente.
Using Key Access Justifications together with Cloud External Key Manager, customers receive: - [...illusioni...] - [...fantasie...] - A commitment from Google Cloud to protect the integrity of our controls and the justifications.
Il fondamento del meccanismo di sicurezza non è la locazione delle chiavi, ma la fiducia nelle promesse di Google. Infatti quelle chiavi, storate presso "terze parti fidate in Europa" e richieste ogni volta che esiste una giustificazione accettabile, possono essere comunque copiate da chiunque vi abbia accesso. Ma ogni volta che servono per decifrare qualcosa, i server e gli amministratori di Google li richiedono alla terza parte, le prendono, le usano e poi le cancellano. Non gli danno nemmeno una sbirciatina! Promesso! :-D Perché mai dovrebbero farlo? [0] Giacomo [0] https://www.forbes.com/sites/thomasbrewster/2021/10/04/google-keyword-warran... https://off-guardian.org/2021/07/08/meet-jigsaw-googles-intelligence-agency/ https://www.theguardian.com/technology/2019/nov/12/google-medical-data-proje... [1] https://cloud.google.com/blog/products/identity-security/new-security-tools-... [2] https://cloud.google.com/blog/products/containers-kubernetes/exploring-conta... [3] https://www.fortanix.com/blog/2019/11/keeping-the-keys-to-your-kingdom-googl... [4] https://cloud.google.com/files/gcp-trust-whitepaper.pdf [5] https://cloud.google.com/blog/products/identity-security/how-google-cloud-is...
Scusa Giovanni, perdo colpi: ti ho linkato tutta la fuffa commerciale e non la documentazione tecnica. Guarda qui: https://cloud.google.com/kms/docs/ekm#how_it_works e qui https://support.fortanix.com/hc/en-us/articles/360030816111-Using-Fortanix-S... (la documentazione di uno dei key manager esterni disponibili al momento) Giacomo
participants (4)
-
380° -
D. Davide Lamanna -
Giacomo Tesio -
J.C. DE MARTIN