Versleuteling van 'data in transit' in Google Cloud

Dit is de derde whitepaper waarin wordt beschreven hoe Google versleuteling gebruikt om uw gegevens te beschermen. In deze whitepaper vindt u meer informatie over de versleuteling van 'data in transit' in Google Cloud, inclusief Google Cloud Platform en G Suite.

Voor alle Google-producten streven we ernaar klantgegevens goed beveiligd te houden. Daarnaast willen we zo transparant mogelijk zijn over de manier waarop we deze gegevens beveiligen.

De inhoud van dit document is geldig vanaf december 2017. Deze whitepaper beschrijft de stand van zaken op het moment van schrijven. Het beveiligingsbeleid en de beveiligingssystemen van Google Cloud kunnen in de toekomst worden gewijzigd, aangezien we de bescherming van onze klanten voortdurend verbeteren.

Afspeelknop

Versleuteling van 'data in transit' in Google Cloud

Samenvatting voor CIO's

  • Google hanteert meerdere beveiligingsmaatregelen om de authenticiteit, integriteit en privacy van 'data in transit' te bewaken.
  • Voor de toepassingen die in deze whitepaper worden besproken, versleutelt en verifieert Google alle 'data in transit' op een of meerdere netwerklagen als de gegevens worden verplaatst buiten de fysieke begrenzingen die niet door of namens Google worden beheerd. 'Data in transit' binnen een fysieke begrenzing die wel door of namens Google wordt beheerd, worden in het algemeen geverifieerd, maar niet altijd versleuteld.
  • Afhankelijk van de verbinding die wordt gemaakt, past Google standaard beveiligingsmethoden toe op 'data in transit'. We gebruiken bijvoorbeeld TLS om de communicatie tussen de gebruiker en de Google Front End (GFE) te beveiligen.
  • Google Cloud-klanten met aanvullende vereisten voor de gegevensversleuteling via WAN kunnen ervoor kiezen om aanvullende beveiligingsmethoden voor gegevens te implementeren wanneer deze worden verplaatst van een gebruiker naar een app of van de ene virtuele machine naar de andere. Enkele van die beveiligingsmethoden zijn IPsec-tunnels, Gmail S/MIME, beheerde SSL-certificaten en Istio.
  • Google werkt actief samen met de branche om de versleuteling van 'data in transit' overal en voor iedereen mogelijk te maken. We hebben verschillende opensource-projecten die de versleuteling van 'data in transit' en gegevensbeveiliging op het internet in het algemeen bevorderen, waaronder certificaattransparantie, Chrome-API's en beveiligde SMTP.
  • Google wil graag marktleider blijven op het gebied van versleuteling van 'data in transit'. Daarom stellen we bronnen ter beschikking voor de ontwikkeling en verbetering van versleutelingstechnologieën. Zelf werken we onder meer aan innovaties op het gebied van sleuteltransparantie en postkwantum-cryptografie.

Inleiding

Beveiliging is vaak een doorslaggevende factor bij het kiezen van een openbare cloudprovider. Bij Google heeft veiligheid de hoogste prioriteit. We werken onvermoeibaar aan de bescherming van uw gegevens, of deze nu worden overgedragen via internet, verplaatst binnen de infrastructuur van Google of opgeslagen op onze servers.

In de beveiligingsstrategie van Google staan verificatie, integriteit en versleuteling centraal, zowel voor 'data at rest' als voor 'data in transit'. In deze whitepaper beschrijven we onze aanpak voor de versleuteling van 'data in transit' in Google Cloud.

Lees het artikel over de versleuteling van 'data at rest' in Google Cloud Platform voor informatie over 'data at rest'. Voor een overzicht van alle Google-beveiliging gaat u naar Overzicht van het beveiligingsontwerp van de infrastructuur van Google.

Doelgroep: Dit document is gericht op CISO's en beveiligingsteams die Google Cloud gebruiken of overwegen dit te gaan doen.

Vereisten: Naast deze inleiding gaan we uit van een basiskennis van versleuteling en cryptografische primitieven.

Verificatie, integriteit en versleuteling

Google hanteert meerdere beveiligingsmaatregelen om de authenticiteit, integriteit en privacy van 'data in transit' te bewaken.

  • Verificatie: We verifiëren de gegevensbron (een mens of een proces) en de bestemming.
  • Integriteit: We zorgen dat de gegevens die u stuurt, ongewijzigd op hun bestemming aankomen.
  • Versleuteling: We houden uw 'data in transit' privé door deze onbegrijpelijk te maken. Versleuteling is het proces waarbij leesbare gegevens (niet-versleutelde tekst) onleesbaar worden gemaakt (versleutelde tekst) met als doel te zorgen dat de leesbare tekst alleen toegankelijk is voor partijen die door de eigenaar van de gegevens zijn gemachtigd. De algoritmen die worden gebruikt in het versleutelingsproces zijn openbaar, maar de benodigde sleutel om de versleutelde tekst te ontsleutelen, is privé. Versleuteling van 'data in transit' maakt vaak gebruik van asymmetrische sleuteluitwisseling (zoals Diffie-Hellman op basis van elliptische krommen) om een gedeelde symmetrische sleutel te definiëren die wordt gebruikt voor gegevensversleuteling. Zie Introduction to Modern Cryptography voor meer informatie over versleuteling.

Versleuteling kan worden gebruikt om gegevens in drie toestanden te beveiligen:

  • De versleuteling van 'data at rest' beschermt uw gegevens tegen systeemhacks of gegevensonderschepping door de gegevens te versleutelen tijdens de opslag. Voor de versleuteling van 'data at rest' wordt vaak de Advanced Encryption Standard (AES) gebruikt.
  • De versleuteling van 'data in transit' beschermt uw gegevens als deze tijdens communicatie tussen uw site en de cloudprovider of tussen twee services worden onderschept. Deze bescherming wordt bereikt door de gegevens voor verzending te versleutelen, de eindpunten te verifiëren en de gegevens bij aankomst te ontsleutelen en te verifiëren. Transport Layer Security (TLS) wordt bijvoorbeeld vaak gebruikt om 'data in transit' te versleutelen voor transportbeveiliging. En Secure/Multipurpose Internet Mail Extensions (S/MIME) wordt vaak gebruikt voor beveiliging van e-mailberichten.
  • De versleuteling van 'data in use' beschermt uw gegevens wanneer deze door servers worden gebruikt om berekeningen uit te voeren, bijvoorbeeld met homomorfe versleuteling.

Versleuteling maakt deel uit van een bredere beveiligingsstrategie. Bij versleuteling van 'data in transit' worden uw gegevens beschermd tegen potentiële aanvallers nadat een verbinding tot stand is gebracht en geverifieerd. Hierbij wordt het volgende gedaan:

  • De noodzaak om te vertrouwen op de lagere lagen van het netwerk wordt weggenomen (gewoonlijk worden deze door derden aangeboden).
  • Het potentiële aanvalsoppervlak wordt verkleind.
  • Er wordt voorkomen dat aanvallers toegang krijgen tot gegevens als de communicatie wordt onderschept.

Met de juiste verificatie, integriteit en versleuteling kunnen gegevens die worden verplaatst tussen gebruikers, apparaten of processen worden beschermd in een vijandige omgeving. In de rest van dit artikel wordt uitgelegd waar en hoe Google 'data in transit' versleutelt.

De netwerkinfrastructuur van Google

Fysieke begrenzingen van een VPC-netwerk (Virtual Private Cloud)

Google past verschillende beveiligingsmaatregelen toe op 'data in transit' wanneer deze worden overgedragen buiten een fysieke begrenzing die door of namens Google wordt beheerd. Een fysieke begrenzing vormt de barrière van een fysieke ruimte die door of namens Google wordt beheerd en waar we strenge beveiligingsmaatregelen kunnen waarborgen. Fysieke toegang tot deze locaties is beperkt en wordt intensief bewaakt. Slechts een klein percentage van alle Google-medewerkers heeft toegang tot deze hardware. 'Data in transit' binnen deze fysieke begrenzingen worden in het algemeen geverifieerd, maar niet altijd versleuteld. U kunt kiezen welke aanvullende beveiligingsmaatregelen moeten worden toegepast op basis van uw bedreigingsmodel.

Vanwege de schaal van het wereldwijde internet kunnen we deze zelfde fysieke beveiligingsmaatregelen niet instellen voor de glasvezelverbindingen in ons WAN, of waar dan ook buiten de fysieke begrenzingen die door of namens Google worden beheerd. Daarom handhaven we automatisch aanvullende beveiligingsmethoden buiten onze fysieke vertrouwensbegrenzing. Deze beveiligingsmethoden omvatten de versleuteling van 'data in transit'.

Hoe verkeer wordt doorgestuurd

In het vorige gedeelte hebben we de fysieke begrenzingen van een VPC-netwerk besproken en hoe we verschillende beveiligingsmaatregelen toepassen op gegevens die buiten deze begrenzingen worden verzonden. Voor een volledig begrip van de manier waarop versleuteling van 'data in transit' werkt bij Google, moeten we ook uitleggen hoe het verkeer wordt doorgestuurd via internet. In dit gedeelte beschrijven we daarom hoe verzoeken van een eindgebruiker bij de juiste Google Cloud-service of klant-app terechtkomen en hoe verkeer van de ene service naar de andere wordt doorgestuurd.

Een Google Cloud-service is een modulaire cloudservice die we aanbieden aan onze klanten. Voorbeelden van deze services zijn computers, gegevensopslag, gegevensanalyse en machine learning. Google Cloud Storage en Gmail zijn bijvoorbeeld allebei services van Google Cloud. Een klant-app is een app die wordt gehost op Google Cloud en die u als Google-klant kunt ontwerpen en implementeren met Google Cloud-services. Klant-apps of partneroplossingen die worden gehost op Google Cloud, worden niet beschouwd als Google Cloud-services1. Een app die u ontwerpt met Google App Engine, Google Kubernetes Engine of een VM in Google Compute Engine is bijvoorbeeld een klant-app.

De vijf soorten routingverzoeken die hieronder worden besproken, worden getoond in afbeelding 1. In deze afbeelding ziet u de interacties tussen de verschillende netwerkcomponenten en de aanwezige beveiliging voor elke verbinding.

Van een eindgebruiker (internet) naar een Google Cloud-service

Google Cloud-services accepteren verzoeken van over de hele wereld met behulp van een wereldwijd gedistribueerd systeem dat Google Front End (GFE) wordt genoemd. GFE houdt inkomend HTTP(S)-, TCP- en TLS-proxyverkeer tegen, biedt tegenmaatregelen tegen DDoS-aanvallen en zorgt voor de routing en load balancing van verkeer naar de Google Cloud-services zelf. Overal ter wereld bestaan er GFE-punten, met routes die worden aangekondigd via unicast of Anycast.

GFE-proxyverkeer naar Google Cloud-services. GFE's sturen het verzoek van de gebruiker via de backbone van ons netwerk door naar een Google Cloud-service. Deze verbinding wordt geverifieerd en versleuteld van GFE naar de front end van de Google Cloud-service of klant-app, wanneer de communicatie een fysieke begrenzing verlaat die door of namens Google wordt beheerd. In afbeelding 1 ziet u deze interactie (aangeduid als verbinding A).

Van een eindgebruiker (internet) naar een klant-app die wordt gehost op Google Cloud

Er zijn verschillende manieren waarop verkeer vanaf het internet kan worden doorgestuurd naar een klant-app die wordt gehost op Google Cloud. De manier waarop uw verkeer wordt doorgestuurd, is afhankelijk van uw configuratie, zoals hieronder wordt uitgelegd. In afbeelding 1 ziet u deze interactie (aangeduid als verbinding B).

Een externe load balancer met Google Cloud HTTP(S)- of TCP/SSL-proxy-load balancer gebruiken

Voor HTTP(S)-load balancing, TCP-proxy-load balancing en SSL-proxy-load balancing versleutelt Google automatisch verkeer tussen Google Front Ends (GFE's) en uw backends die zich in Google Cloud bevinden.

Naast deze versleuteling op netwerkniveau kunt u een beveiligd protocol gebruiken, zoals SSL, HTTPS of HTTP/2 (met TLS), als backend-serviceprotocol voor de op GFE gebaseerde load balancers, en voor interne HTTP(S)-load balancing en Traffic Director.

Wanneer een load balancer via een beveiligd backend-serviceprotocol verbinding maakt met uw backends, fungeert de GFE als SSL- of HTTPS-client. Als een proxy aan de clientzijde is geconfigureerd met Traffic Director en via een beveiligd backend-serviceprotocol verbinding maakt met uw backends, fungeert de proxy als SSL- of HTTPS-client.

In de volgende gevallen wordt een beveiligd protocol aanbevolen om verbinding te maken met backend-instanties:

  • Als er een controleerbare, versleutelde verbinding van de load balancer (of Traffic Director) naar de backend-instanties vereist is.

  • Als de load balancer verbinding maakt met een backend-instantie die zich buiten Google Cloud bevindt (via een internet-NEG). Communicatie met een internet-NEG-backend kan via het openbare internet lopen. Wanneer de load balancer verbinding maakt met een internet-NEG, moet het certificaat worden ondertekend door een openbare certificeringsinstantie en voldoen aan de validatievereisten.

Houd rekening met de volgende vereisten als u een beveiligd protocol wilt gebruiken tussen de load balancer en uw backends:

  • U moet de backend-services van uw load balancer configureren voor het gebruik van het SSL- (TLS-), HTTPS- of HTTP/2-protocol.

  • Voor backend-instanties moet u software configureren voor verkeer via hetzelfde protocol als de backend-service. Als de backend-service bijvoorbeeld HTTPS gebruikt, moet u uw backend-instanties configureren om HTTPS te gebruiken. Als u het HTTP/2-protocol gebruikt, moeten uw backends TLS gebruiken. Raadpleeg de softwaredocumentatie van uw backend-instantie voor configuratie-instructies.

  • U moet privésleutels en certificaten installeren op uw backend-instanties. Deze certificaten hoeven niet overeen te komen met het SSL-certificaat van de load balancer. Raadpleeg de softwaredocumentatie van uw backend-instantie voor installatie-instructies.

  • De software die op uw backend-instanties wordt uitgevoerd, moet worden geconfigureerd als SSL- of HTTPS-server. Raadpleeg de softwaredocumentatie van uw backend-instantie voor configuratie-instructies.

Houd rekening met het volgende als u instantiegroep- of zone-NEG-backends gebruikt:

  • Als een GFE een TLS-sessie met backends start, gebruikt de GFE de SNI-extensie (Server Name Indication) niet.

  • Als een GFE verbinding maakt met backends binnen Google Cloud, accepteert de GFE alle certificaten van uw backends. GFE's voeren geen certificaatvalidatie uit. Het certificaat wordt bijvoorbeeld zelfs als geldig beschouwd in de volgende omstandigheden:

    • Het certificaat is zelfondertekend.
    • Het certificaat is ondertekend door een onbekende certificeringsinstantie (CA).
    • Het certificaat is verlopen of is nog niet geldig.
    • De kenmerken CN en subjectAlternativeName komen niet overeen met een Host-header of DNS PTR-record.

Een rechtstreekse verbinding met een VM gebruiken in combinatie met een extern IP-adres of een IP-adres van een load balancer voor het netwerk

Als u verbinding maakt via het externe IP-adres van de VM of via een IP-adres met een load balancer voor het netwerk, loopt de verbinding niet via de GFE. Deze verbinding wordt standaard niet versleuteld en de beveiliging ervan moet door de gebruiker zelf worden verzorgd.

Cloud VPN gebruiken

Als u via een VPN verbinding maakt tussen een lokale host en een VM van Google Cloud, gaat de verbinding van/naar uw lokale host, naar de lokale VPN, naar de VPN van Google, naar de VM van Google Cloud. De verbinding gaat niet via de GFE. De verbinding tussen de lokale VPN en de VPN van Google wordt met IPsec beveiligd. De verbinding van de VPN van Google naar de VM van Google Cloud wordt geverifieerd en versleuteld wanneer deze communicatie een fysieke begrenzing verlaat die door of namens Google wordt beheerd.

Een toegewezen interconnect van Google Cloud gebruiken

Als u verbinding maakt via een toegewezen interconnect, gaat de verbinding rechtstreeks van/naar uw lokale host en niet via de GFE. Deze verbinding is standaard niet versleuteld en de beveiliging ervan wordt naar eigen goeddunken van de gebruiker aangeboden. Met het Transport Layer Security (TLS) laag 7-versleutelingsprotocol kunt u app-verkeer via een toegewezen interconnect versleutelen.

Tussen virtuele machines

Voor routing tussen VM's binnen uw VPC-netwerk in ons productienetwerk, waarbij VPC-subnetwerkbereiken worden gebruikt, is mogelijk routing van gegevens vereist buiten de fysieke begrenzingen die door of namens Google worden beheerd. Voorbeelden van routing tussen VM's zijn:

  • VM's van Compute Engine die verzoeken naar elkaar sturen
  • Een klant-VM die verbinding maakt met een door Google beheerde VM zoals Cloud SQL

Verbindingen tussen VM's worden versleuteld als ze een fysieke begrenzing verlaten en worden binnen de fysieke begrenzing geverifieerd. Verkeer tussen VM's waarbij externe IP-adressen worden gebruikt, wordt standaard niet versleuteld. De beveiliging moet door de gebruiker zelf worden verzorgd. In afbeelding 1 ziet u deze interactie (aangeduid als verbinding C).

Verbinding maken met Google-API's en -services

De verwerking van het verkeer hangt af van de locatie van de Google Cloud-service:

  • De meeste Google-API's en -services worden gehost op Google Front Ends (GFE's). Maar sommige services worden gehost op door Google beheerde instanties. Privétoegang tot services en GKE-hoofdinstanties voor privéclusters worden bijvoorbeeld gehost op door Google beheerde instanties.

    Met Private Google Access hebben VM's zonder externe IP-adressen toegang tot ondersteunde Google-API's en -services, waaronder klant-apps die worden gehost op App Engine. Raadpleeg Opties voor privétoegang tot services voor meer informatie over toegang tot Google-API's en -services.

  • Als een Compute Engine-VM-instantie verbinding maakt met het externe IP-adres van een andere Compute Engine-VM-instantie, blijft het verkeer binnen het productienetwerk van Google. Bij systemen die buiten het productienetwerk van Google vallen en die verbinding maken met een extern IP-adres van een Compute Engine-VM-instantie, loopt het verkeer via het internet.

    In afbeelding 1 ziet u een extern pad (aangeduid als verbinding D). Voorbeelden van dit soort routingverzoeken zijn:

    • Van een Compute Engine-VM naar Google Cloud Storage
    • Van een Compute Engine-VM naar een Machine Learning API

Met Google Cloud-services kunt u deze verbindingen van de VM naar de GFE standaard beveiligen met TLS2. De verbinding wordt geverifieerd vanaf de GFE naar de service en versleuteld als de verbinding een fysieke begrenzing verlaat.

Tussen Google Cloud-services

Routing van de ene productieservice naar de andere vindt plaats op de backbone van ons netwerk en vereist routing van het verkeer buiten de fysieke begrenzingen die door of namens Google worden beheerd. In afbeelding 1 ziet u deze interactie (aangeduid als verbinding E). Een voorbeeld van dergelijk verkeer is een Google Cloud Storage-gebeurtenis die Google Cloud Functions activeert. Verbindingen tussen productieservices worden versleuteld als ze een fysieke begrenzing verlaten en worden geverifieerd binnen de fysieke begrenzing.

De gebruiker wordt over fysieke grenzen doorgestuurd naar Google Cloud-services met behulp van ALTS-versleuteling.

Afbeelding 1: Standaardbescherming en opties voor een VPC-netwerk

Standaardmethoden voor versleuteling van 'data in transit'

Google gebruikt verschillende versleutelingsmethoden voor 'data in transit': zowel standaardmethoden als methoden die gebruikers kunnen configureren. Het type versleuteling dat wordt gebruikt, is afhankelijk van de OSI-laag, het type service en de fysieke component van de infrastructuur. In afbeelding 2 en 3 hieronder ziet u de optionele beveiligingsmethoden en standaard beveiligingsmethoden van Google Cloud voor de lagen 3, 4 en 7.

Versleutelingsopties voor lagen 3 en 4 omvatten dataverkeer naar de VM en over grenzen heen.

Afbeelding 2: Standaardbescherming en opties voor de lagen 3 en 4 in Google Cloud

Versleutelingsopties voor laag 7 omvatten opties voor 'data in transit' tussen VM's en naar Google Front End.

Afbeelding 3: Standaardbescherming en opties voor laag 7 in Google Cloud3

In de rest van dit gedeelte worden de standaard beveiligingsmethoden beschreven die Google gebruikt om 'data in transit' te beschermen.

Versleuteling tussen de gebruiker en Google Front End

Tegenwoordig gebruiken veel systemen HTTPS om te communiceren via internet. HTTPS biedt beveiliging door gebruik te maken van een TLS-verbinding, die de authenticiteit, integriteit en privacy van verzoeken en reacties garandeert. De ontvanger heeft een openbaar/privé-sleutelpaar en een X.509-certificaat voor serververificatie van een certificeringsinstantie (CA) nodig om HTTPS-verzoeken te accepteren. Het sleutelpaar en het certificaat helpen de verzoeken van een gebruiker op de app-laag (laag 7) te beschermen door te bewijzen dat de ontvanger eigenaar is van de domeinnaam waarvoor de verzoeken bestemd zijn. In de volgende subgedeelten worden de componenten van versleuteling van de gebruiker naar GFE besproken: TLS, BoringSSL en de certificeringsinstantie (CA) van Google. Onthoud dat niet alle klantpaden via de GFE lopen. De GFE wordt met name gebruikt voor verkeer van een gebruiker naar een Google Cloud-service en voor verkeer van een gebruiker naar een klant-app die wordt gehost op Google Cloud en die Google Cloud Load Balancing gebruikt.

Transport Layer Security (TLS)

Als een gebruiker een verzoek stuurt naar een Google Cloud-service, beveiligen we de 'data in transit'. We bieden verificatie, integriteit en versleuteling en maken gebruik van HTTPS met een certificaat van een (openbare) certificeringsinstantie (CA) voor het web. Alle gegevens die de gebruiker naar de GFE stuurt, worden 'in transit' versleuteld met Transport Layer Security (TLS) of QUIC. GFE spreekt een bepaald versleutelingsprotocol af met de client, afhankelijk van wat de client kan ondersteunen. GFE spreekt waar mogelijk modernere versleutelingsprotocollen af.

De geschaalde TLS-versleuteling van GFE is niet alleen van toepassing op interacties van eindgebruikers met Google, maar maakt ook API-interacties met Google via TLS mogelijk, onder andere in Google Cloud. Daarnaast wordt onze TLS-versleuteling in Gmail gebruikt om e-mails uit te wisselen met externe e-mailservers (meer informatie vindt u in TLS als vereiste in Gmail).

Google is marktleider in zowel het toepassen van TLS als het verbeteren van de implementatie hiervan. Daarom hebben we veel beveiligingsfuncties van TLS standaard ingeschakeld. Sinds 2011 gebruiken we bijvoorbeeld forward secrecy in onze TLS-implementatie. Forward secrecy zorgt ervoor dat de sleutel die een verbinding beschermt niet wordt bewaard, zodat een aanvaller die een bericht onderschept en leest, eerdere berichten niet kan lezen.

BoringSSL

BoringSSL is een door Google onderhouden opensource-implementatie van het TLS-protocol, afgesplitst van OpenSSL, die grotendeels werkt met de interface van OpenSSL. Google heeft BoringSSL afgesplitst van OpenSSL om OpenSSL te vereenvoudigen, zowel voor intern gebruik als om Chromium- en Android-opensourceprojecten beter te kunnen ondersteunen. BoringCrypto, de kern van BoringSSL, is gevalideerd volgens FIPS 140-2 niveau 1.

TLS in de GFE wordt geïmplementeerd met BoringSSL. In tabel 1 ziet u de versleutelingsprotocollen die GFE ondersteunt bij communicatie met clients.

Protocollen Verificatie Sleuteluitwisseling Versleuteling Hash-functies
TLS 1.34 RSA 2048 Curve25519 AES-128-GCM SHA384
TLS 1.2 ECDSA P-256 P-256 (NIST secp256r1) AES-256-GCM SHA256
TLS 1.1     AES-128-CBC SHA18
TLS 1.05     AES-256-CBC MD59
QUIC6     ChaCha20-Poly1305  
      3DES7  

Tabel 1: Versleuteling geïmplementeerd in Google Front End voor Google Cloud-services en in de cryptografische bibliotheek van BoringSSL

De certificeringsinstantie (CA) van Google

Als onderdeel van TLS moet een server de eigen identiteit bewijzen aan de gebruiker wanneer deze een verbindingsverzoek ontvangt. Deze identiteitsverificatie wordt bereikt in het TLS-protocol door de server een certificaat te bieden met de gestelde identiteit. Het certificaat bevat zowel de DNS-hostnaam als de openbare sleutel van de server. Eenmaal aangeboden, wordt het certificaat ondertekend door een uitgevende certificeringsinstantie (CA) die wordt vertrouwd door de gebruiker die de verbinding aanvraagt10. Hierdoor hoeven gebruikers die een verbinding met de server aanvragen, alleen de root-CA te vertrouwen. Als de server overal benaderbaar moet zijn, moet de root-CA wereldwijd bekend zijn bij de clientapparaten. Tegenwoordig hebben de meeste browsers en andere TLS-clientimplementaties in hun 'rootopslag' elk een eigen verzameling root-CA's die als vertrouwd zijn geconfigureerd.

In het verleden had Google een eigen uitgevende CA, die we gebruikten om certificaten voor Google-domeinen te ondertekenen. We hadden echter geen eigen root-CA. Tegenwoordig worden onze CA-certificaten kruiselings ondertekend door meerdere root-CA's die overal ter wereld zijn gesitueerd, waaronder Symantec ('GeoTrust') en root-CA's die voorheen werden beheerd door GlobalSign ('GS Root R2' en 'GS Root R4').

In juni 2017 hebben we een overgang aangekondigd naar het gebruik van root-CA's die eigendom zijn van Google. Na verloop van tijd willen we gebruik gaan maken van een volledig gedistribueerde root-CA, die certificaten afgeeft voor Google-domeinen en voor onze klanten.

Migratie en roulatie van rootsleutels

Sleutels van de root-CA worden niet vaak gewijzigd, omdat voor migratie naar een nieuwe root-CA alle browsers en apparaten dat certificaat moeten vertrouwen. Dit kost veel tijd. Daarom blijven we tijdens een overgangsperiode nog afhankelijk van meerdere root-CA's van derden, ondanks dat Google nu zijn eigen root-CA's beheert. Zo houden we rekening met verouderde apparaten bij migratie naar onze eigen root-CA.

Er is een sleutelceremonie vereist om een nieuwe root-CA te maken. Bij Google geldt voor de ceremonie het vereiste dat minimaal drie van de zes gemachtigde personen fysiek bij elkaar komen om hardwaresleutels te gebruiken die in een kluis zijn opgeslagen. Deze personen ontmoeten elkaar in een speciale ruimte die beschermd is tegen elektromagnetische storing en een hardwarebeveiligingsmodule (Hardware Security Module, HSM) met een air gap heeft, om een set sleutels en certificaten te genereren. De speciale ruimte bevindt zich op een beveiligde locatie in een datacenter van Google. Aanvullende controles, zoals fysieke beveiligingsmaatregelen, camera's en andere personen die hen observeren, zorgen ervoor dat het proces verloopt zoals gepland. Als de ceremonie slaagt, is het gegenereerde certificaat identiek aan een voorbeeldcertificaat, met uitzondering van de naam van de uitgever, de openbare sleutel en de handtekening. Het resulterende root-CA-certificaat wordt vervolgens aangeboden aan browser- en apparaatrootprogramma's, zodat deze het certificaat kunnen opnemen. Dit proces zorgt ervoor dat er duidelijkheid bestaat over de privacy en veiligheid van gekoppelde privésleutels, zodat er tien jaar of langer op de sleutels kan worden vertrouwd.

Zoals eerder beschreven, gebruiken CA's hun privésleutels om certificaten te ondertekenen en worden met deze certificaten identiteiten geverifieerd bij het initiëren van een TLS-handshake als onderdeel van een gebruikerssessie. Servercertificaten worden ondertekend door tussenliggende CA's. Het maken hiervan is vergelijkbaar met het maken van een root-CA. De certificaten van de tussenliggende CA worden gedistribueerd als onderdeel van de TLS-sessie, zodat het eenvoudiger is om te migreren naar een nieuwe tussenliggende CA. Bovendien kan de CA-beheerder met deze distributiemethode het sleutelmateriaal van de root-CA offline houden.

De beveiliging van een TLS-sessie is afhankelijk van hoe goed de sleutel van de server wordt beveiligd. De levensduur van TLS-certificaten bij Google is beperkt tot ongeveer drie maanden. De certificaten worden bovendien ongeveer elke twee weken gerouleerd om het risico op gehackte sleutels verder te beperken.

Een client die eerder verbinding heeft gemaakt met een server, kan een privéticketsleutel11 gebruiken om een eerdere sessie te hervatten met een verkorte TLS-handshake. Hierdoor zijn deze tickets zeer waardevol voor aanvallers. Google rouleert de ticketsleutels minstens één keer per dag en laat de sleutels voor alle property's om de drie dagen verlopen. In het artikel Measuring the Security Harm of TLS Crypto Shortcuts vindt u meer informatie over het rouleren van ticketsleutels van sessies.

Van Google Front End naar front ends van apps

Zoals besproken bij Hoe verkeer wordt doorgestuurd maakt de gebruiker verbinding met een GFE binnen een andere fysieke begrenzing dan de gewenste service en de bijbehorende front end van de app. Als dit gebeurt, wordt het verzoek van de gebruiker en elk ander protocol van laag 7 (zoals HTTP) beschermd door TLS of geïntegreerd in een RPC die wordt beschermd met Transportbeveiliging op de app-laag (Application Layer Transport Security, ALTS), zoals besproken bij Verificatie, integriteit en versleuteling bij overdracht tussen services. Deze RPC's worden geverifieerd en versleuteld.

Voor Google Cloud-services worden RPC's standaard beveiligd met ALTS. Voor klant-apps die worden gehost op Google Cloud en waarvan de routing van verkeer verloopt via Google Front End (bijvoorbeeld als de apps de Google Cloud Load Balancer gebruiken), wordt verkeer naar de VM beveiligd met de virtuele netwerkversleuteling van Google Cloud. Deze versleuteling beschrijven we in het volgende gedeelte.

Versleuteling en verificatie in het virtuele netwerk van Google Cloud

Dankzij de virtuele netwerkinfrastructuur van Google Cloud is het mogelijk om verkeer te versleutelen als het onze fysieke begrenzingen verlaat. Versleuteling wordt uitgevoerd op de netwerklaag en is van toepassing op privé-IP-verkeer binnen dezelfde Virtual Private Cloud (VPC) of op peer-VPC-netwerken.

We gaan ervan uit dat elk netwerk dat een fysieke begrenzing overschrijdt die niet door of namens Google wordt beheerd, kan worden gehackt door een actieve vijand die verkeer in dat netwerk kan afkijken, injecteren of veranderen. Wij gebruiken versleuteling om de integriteit en privacy van communicatie te waarborgen wanneer gegevens worden overgedragen buiten fysieke begrenzingen die wij niet beheren.

We gebruiken de Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) met een 128-bits sleutel (AES-128-GCM) om versleuteling op de netwerklaag te implementeren. Elk paar communicerende hosts brengt een sessiesleutel tot stand. Dit gebeurt via een besturingskanaal dat wordt beschermd met ALTS voor geverifieerde en versleutelde communicatie. De sessiesleutel wordt gebruikt om alle communicatie van VM's naar VM's tussen die hosts te versleutelen. De sessiesleutels worden regelmatig gerouleerd.

Op de netwerklaag (laag 3) verifieert het virtuele netwerk van Google Cloud al het verkeer tussen VM's. Deze verificatie wordt bereikt door middel van beveiligingstokens en zorgt ervoor dat een gehackte host wordt beschermd tegen spoofingpakketten in het netwerk.

Tijdens de verificatie worden beveiligingstokens opgenomen in een tunnelheader met verificatie-informatie over de afzender en de ontvanger. Het besturingsvlak12 aan de zijde van de verzender stelt de token in en de ontvangende host valideert de token. Beveiligingstokens worden vooraf gegenereerd voor elke stroom en bestaan uit een tokensleutel (met de informatie van de afzender) en het hostgeheim. Er is één geheim voor elk bron-ontvangerpaar van fysieke begrenzingen die door of namens Google worden beheerd. In afbeelding 4 ziet u hoe tokensleutels, hostgeheimen en beveiligingstokens worden gemaakt.

De componentonderdelen van een beveiligingstoken kunnen een tokensleutel en een hostgeheim omvatten, samen met hun afhankelijkheden.

Afbeelding 4: Beveiligingstokens

Het geheim van een fysieke begrenzing is een 128-bits pseudowillekeurig nummer, waarvan hostgeheimen worden afgeleid via een HMAC-SHA1. Het geheim van de fysieke begrenzing wordt afgesproken met een handshake tussen de netwerkbesturingsvlakken van een paar fysieke begrenzingen. Om de paar uur wordt er een nieuw geheim afgesproken. De beveiligingstokens die worden gebruikt voor individuele verificatie bij overdracht tussen VM's en die worden afgeleid uit deze en andere invoer, zijn HMAC's die worden afgesproken voor een bepaald zender/ontvanger-paar.

Verificatie, integriteit en versleuteling bij overdracht tussen services

Binnen de infrastructuur van Google gebruiken we op de app-laag (laag 7) onze Transportbeveiliging op de app-laag (Application Layer Transport Security, ALTS) voor de verificatie, integriteit en versleuteling van Google RPC-aanroepen van de GFE naar een service en tussen services onderling.

ALTS maakt gebruik van serviceaccounts voor verificatie. Elke service die op de infrastructuur van Google wordt uitgevoerd, wordt uitgevoerd als een serviceaccountidentiteit met bijbehorende cryptografische gegevens. Een service gebruikt de gegevens voor verificatie bij het maken of ontvangen van RPC's van andere services. ALTS verifieert deze gegevens met behulp van een interne CA.

Binnen een fysieke grens die wordt beheerd door of namens Google, biedt ALTS zowel verificatie als integriteit voor RPC's in de modus 'verificatie en integriteit'. Voor verkeer via het WAN buiten de fysieke begrenzingen die door of namens Google worden beheerd, dwingt ALTS automatisch versleuteling af voor infrastructuur-RPC-verkeer in de modus 'verificatie, integriteit en privacy'. Op dit moment maakt alle verkeer naar Google-services (inclusief Google Cloud-services) gebruik van deze beveiliging.

ALTS wordt ook gebruikt voor het integreren van andere laag 7-protocollen (zoals HTTP) in infrastructuur-RPC-mechanismen voor de overdracht van verkeer van de Google Front End naar een front end van een app. Deze beveiliging isoleert de app-laag en verwijdert alle afhankelijkheden van de beveiliging van het netwerkpad.

Services kunnen worden geconfigureerd om ALTS-communicatie alleen te accepteren en te sturen in de modus 'verificatie, integriteit en privacy', zelfs als het verkeer zich bevindt binnen fysieke begrenzingen die door of namens Google worden beheerd. Een voorbeeld is de interne service voor sleutelbeheer van Google, die de versleutelingssleutels opslaat en beheert die worden gebruikt om 'data at rest' in de infrastructuur van Google te beschermen.

ALTS-protocol

ALTS heeft een beveiligd handshake-protocol dat vergelijkbaar is met wederzijdse TLS. Twee services die willen communiceren met ALTS gebruiken dit handshake-protocol om communicatieparameters te verifiëren en af te spreken voordat er gevoelige informatie wordt gestuurd. Het protocol is een proces in twee stappen:

  • Stap 1: Handshake De client start een ECDH-handshake (elliptische curve-Diffie Hellman) met de server met behulp van Curve25519. De client en de server hebben elk gecertificeerde, openbare ECDH-parameters als onderdeel van hun certificaat, dat wordt gebruikt tijdens een Diffie Hellman-sleuteluitwisseling. De handshake resulteert in een gemeenschappelijke verkeerssleutel die beschikbaar is op de client en de server. De peer-identiteiten van de certificaten worden op de app-laag beschikbaar gesteld voor gebruik bij autorisatiebeslissingen.
  • Stap 2: Versleuteling van records Gegevens worden op een beveiligde manier van de client naar de server overgedragen met de gemeenschappelijke verkeerssleutel uit stap 1. Versleuteling in ALTS wordt geïmplementeerd met behulp van BoringSSL en andere versleutelingsbibliotheken. Versleuteling is meestal AES-128-GCM, terwijl integriteit wordt geboden door de GMAC van AES-GCM.

In het diagram hieronder ziet u een gedetailleerde voorstelling van de ALTS-handshake. In nieuwere implementaties voert een proceshelper de handshake uit. Er zijn nog steeds enkele gevallen waarin dit rechtstreeks door de apps wordt gedaan.

Client-app werkt met een handshake-service via een proceshelper, en met de server-app via een sleuteluitwisseling.

Afbeelding 5: ALTS-handshake

Zoals beschreven aan het begin van het gedeelte Verificatie, integriteit en versleuteling bij overdracht tussen services, gebruikt ALTS serviceaccounts voor verificatie. Daarbij wordt elke service die wordt uitgevoerd op de infrastructuur van Google, uitgevoerd als een service-identiteit met bijbehorende cryptografische gegevens. Tijdens de ALTS-handshake gebruikt de proceshelper de privésleutels en bijbehorende certificaten die elk client/server-paar gebruikt in de communicatie. De privésleutel en het bijbehorende certificaat (ondertekende protocolbuffer) worden geleverd voor de serviceaccount-identiteit van de service.

ALTS-certificaten Er zijn meerdere soorten ALTS-certificaten:

  • Machinecertificaten: Bieden een identiteit aan kernservices op een specifieke machine. Deze worden ongeveer om de 6 uur gerouleerd.
  • Gebruikerscertificaten: Bieden een eindgebruikersidentiteit aan een Google-technicus die code ontwikkelt. Deze worden ongeveer om de 20 uur gerouleerd.
  • Borg-taakcertificaten: Bieden een identiteit aan taken die worden uitgevoerd op de infrastructuur van Google. Deze worden ongeveer om de 48 uur gerouleerd.

De ondertekeningssleutel voor de rootcertificering wordt opgeslagen in de interne certificeringsinstantie (CA) van Google. Deze houdt geen verband met en is onafhankelijk van onze externe CA.

Versleuteling in ALTS

Versleuteling in ALTS kan worden geïmplementeerd met diverse algoritmen, afhankelijk van de machines die worden gebruikt. De meeste services gebruiken bijvoorbeeld AES-128-GCM13. Meer informatie over ALTS-versleuteling vindt u in tabel 2.

Machines Gebruikte versleuteling van berichten  
Meest voorkomend AES-128-GCM  
Sandy Bridge of ouder AES-128-VCM Gebruikt een VMAC in plaats van een GMAC en is iets efficiënter op deze oudere machines.

Tabel 2: Versleuteling in ALTS

De meeste Google-services gebruiken ALTS of RPC-integratie met ALTS. In gevallen waarin ALTS niet wordt gebruikt, worden andere beveiligingsmethoden gebruikt. Voorbeeld:

  • Sommige services voor machinebeheer op een laag niveau en bootstrapping gebruiken SSH.
  • Sommige infrastructuurlogboekservices op een laag niveau gebruiken TLS of Datagram TLS (DTLS)14.
  • Sommige services met niet-TCP-transporten gebruiken andere cryptografische protocollen of beveiligingsmethoden op netwerkniveau binnen fysieke begrenzingen die door of namens Google worden beheerd.

Bij communicatie tussen VM's en Google Cloud Platform-services wordt TLS en niet ALTS gebruikt voor communicatie met de Google Front End. We beschrijven deze communicatie bij Versleuteling bij overdracht van een virtuele machine naar Google Front End.

Versleuteling bij overdracht van een virtuele machine naar Google Front End

Verkeer van een VM naar GFE maakt gebruik van externe IP-adressen om Google-services te bereiken. U kunt echter ook de functie Private Google Access configureren om alleen IP-adressen van Google te gebruiken voor de verzoeken.

Net als bij verzoeken van een externe gebruiker naar Google, ondersteunen we standaard TLS-verkeer van een VM naar de GFE. De verbinding komt op dezelfde manier tot stand als elke andere externe verbinding. Zie Transport Layer Security (TLS) voor meer informatie over TLS.

Door de gebruiker te configureren opties voor versleuteling van 'data in transit'

Onder Versleuteling van 'data in transit' worden de standaard beveiligingsmaatregelen beschreven die Google heeft ingesteld voor 'data in transit'. In dit gedeelte wordt beschreven welke configuraties onze gebruikers kunnen doorvoeren in deze standaardbeveiligingen.

Overdracht van een lokaal datacenter naar Google Cloud

TLS met externe load balancers van GCLB

Als uw cloudservice een externe load balancer voor een HTTPS- of SSL-proxy van Google gebruikt, beëindigt GFE de TLS-verbindingen van uw gebruikers met behulp van SSL-certificaten die u verstrekt en beheert. Meer informatie over het aanpassen van uw certificaat vindt u in onze documentatie over SSL-certificaten.

IPsec-tunnel met Google Cloud VPN

Als Google Cloud-klant kunt u Google Cloud VPN gebruiken om uw netwerk op locatie op een beveiligde manier te verbinden met uw VPC-netwerk (Virtual Private Cloud) van Google Cloud Platform via een IPsec VPN-verbinding (laag 3). Het verkeer tussen de twee netwerken wordt versleuteld door de ene VPN-gateway en ontsleuteld door de andere VPN-gateway. Zo blijven uw gegevens beveiligd tijdens overdrachten via internet. Bovendien kunt u meerdere tunnels met load balancing instellen via meerdere VPN-gateways. De Google Cloud VPN beschermt uw gegevens op de volgende manieren:

  • Pakketten van uw VM's naar de Cloud VPN blijven binnen het VPC-netwerk. Deze pakketten worden versleuteld door het virtuele netwerk van Google Cloud als ze buiten de fysieke begrenzingen komen die door of namens Google worden beheerd.
  • Pakketten van de Cloud VPN naar uw VPN op locatie worden versleuteld en geverifieerd met behulp van een IPsec-tunnel.
  • Pakketten van uw VPN op locatie naar uw hosts op locatie worden beschermd door de maatregelen die u op uw netwerk heeft doorgevoerd.

Als u een VPN wilt instellen, maakt u een Cloud VPN-gateway en -tunnel op het VPC-netwerk van de gehoste service en geeft u vervolgens toestemming voor verkeer tussen de netwerken. U kunt ook een VPN opzetten tussen twee VPC's.

U kunt uw netwerk verder aanpassen door de IKE-versie (Internet Key Exchange15) voor uw VPN-tunnel op te geven. Er zijn twee IKE-versies waar u uit kunt kiezen: IKEv1 en IKEv2. Elke versie ondersteunt verschillende coderingen. Als u IKEv1 opgeeft, versleutelt Google de pakketten met AES-128-CBC en wordt integriteit geboden via SHA-1 HMAC16. Voor IKEv2 worden verschillende coderingen beschikbaar gesteld en ondersteund. In alle gevallen spreekt Google Cloud VPN het meest beveiligde gemeenschappelijke protocol af dat de peer-apparaten ondersteunen. Volledige instructies voor het instellen van een VPN vindt u in onze documentatie Een VPN-routingoptie kiezen.

Een alternatief voor een Cloud VPN-tunnel (IPsec) is een toegewezen interconnect van Google Cloud. Een toegewezen interconnect biedt een rechtstreekse fysieke verbinding en privé IP-communicatie tussen uw netwerk op locatie en uw VPC-netwerk. De gegevens die via toegewezen interconnect of Partner Interconnect worden verzonden, worden standaard niet versleuteld en moeten daarom op de app-laag worden beveiligd, bijvoorbeeld met behulp van TLS. MACsec (bescherming op laag 2) wordt momenteel niet ondersteund.

Overdracht van gebruikers naar Google Front End

Beheerde SSL-certificaten: gratis en geautomatiseerde certificaten

Als u een app in Google Cloud ontwerpt, kunt u het daarvoor gebruikte SSL-certificaat configureren om de ondersteuning van TLS door GFE te benutten. U kunt bijvoorbeeld de TLS-sessie laten beëindigen in uw app. Deze beëindiging verschilt van de TLS-beëindiging die wordt beschreven bij TLS met externe load balancers van GCLB.

Google biedt ook gratis en geautomatiseerde SSL-certificaten voor extra domeinen in zowel Firebase Hosting als Google App Engine. Deze certificaten zijn alleen beschikbaar voor property's die bij Google worden gehost. Met extra domeinen van Google App Engine kunt u ook uw eigen SSL-certificaten opgeven en een header voor HTTP Strict Transport Security (HSTS) gebruiken.

Zodra uw domein verwijst naar de infrastructuur van Google, verzoeken en verkrijgen we een certificaat voor dat domein om beveiligde communicatie mogelijk te maken. We beheren de privésleutels van de TLS-server (die 2048-bits RSA of secp256r1 ECC zijn) en vernieuwen certificaten namens onze klanten.

TLS als vereiste in Gmail

Zoals besproken bij Transport Layer Security gebruikt Gmail standaard TLS. Gmail registreert en geeft weer of de laatste stap van een e-mail via een TLS-sessie werd uitgevoerd17. Als een Gmail-gebruiker een e-mail uitwisselt met een andere Gmail-gebruiker, worden de e-mails beschermd met TLS, of in sommige gevallen rechtstreeks binnen de app gestuurd. In deze gevallen worden de RPC's die worden gebruikt door de Gmail-toepassing beschermd met ALTS, zoals wordt beschreven bij Verificatie, integriteit en versleuteling bij overdracht tussen services. Voor inkomende berichten van andere e-mailproviders dwingt Gmail TLS niet af. Gmail-beheerders kunnen configureren dat Gmail een beveiligde TLS-verbinding vereist voor alle inkomende en uitgaande e-mails.

Gmail S/MIME

Secure/Multipurpose Internet Mail Extensions (S/MIME) is een standaard voor e-mailbevestiging die verificatie, integriteit en versleuteling biedt. De implementatie van de S/MIME-standaard vereist dat certificaten die zijn gekoppeld aan gebruikers die e-mails sturen, worden gehost in een openbare CA.

Als beheerder kunt u Gmail configureren om S/MIME in te schakelen voor uitgaande e-mails, beleidsregels instellen voor naleving in content en bijlagen, en routingregels maken voor inkomende en uitgaande e-mails. Na de configuratie moet u de openbare certificaten van de gebruikers uploaden naar Gmail met behulp van de Gmail API. Voor gebruikers buiten Gmail moet een eerste bericht ondertekend met S/MIME worden uitgewisseld om S/MIME als standaard in te stellen.

Versleuteling bij overdracht tussen services en tussen VM's

Istio is een opensource-servicemesh die door Google, IBM, Lyft en andere bedrijven is ontwikkeld om het ontdekken en verbinden van services te vereenvoudigen. Istio-verificatie biedt automatische versleuteling van 'data in transit' tussen services en beheer van bijbehorende sleutels en certificaten. Istio kan worden gebruikt in Google Kubernetes Engine en Google Compute Engine.

Als u wederzijdse verificatie en versleuteling voor productietaken wilt implementeren, kunt u istio auth gebruiken. Bij productietaken in Kubernetes kan een CA op clusterniveau dankzij Istio auth certificaten genereren en distribueren die vervolgens worden gebruikt voor mutual Transport Layer Security (mTLS) tussen pods.

Hoe Google het internet helpt met de versleuteling van 'data in transit'

Onder Standaardmethoden voor versleuteling van 'data in transit' en Door de gebruiker te configureren opties voor versleuteling van 'data in transit' werd uitgelegd welke standaard gebruikte en aanpasbare beveiligingsmethoden Google heeft voor 'data in transit' van klanten. Daarnaast werkt Google aan verschillende opensource-projecten en andere activiteiten om het gebruik van versleuteling van 'data in transit' en gegevensbeveiliging op het internet in het algemeen te bevorderen.

Certificaattransparantie

Zoals besproken bij Versleuteling tussen de gebruiker en Google Front End, moet een site eerst een certificaat van een vertrouwde webcertificeringsinstantie (openbare CA) aanvragen om HTTPS aan te bieden. Het is de verantwoordelijkheid van de CA om te controleren of de aanvrager door de domeinhouder is gemachtigd en om ervoor te zorgen dat alle overige informatie in het certificaat juist is. Dit certificaat wordt vervolgens aangeboden aan de browser om de site te verifiëren die de gebruiker probeert te openen. Om te waarborgen dat HTTPS correct wordt geverifieerd, is het belangrijk om te zorgen dat CA's alleen certificaten afgeven die de domeinhouder heeft gemachtigd.

Certificaattransparantie (CT) is een project dat Google in maart 2013 heeft gelanceerd om sitebeheerders en domeinhouders een manier te bieden om te detecteren of een CA ongemachtigde of onjuiste certificaten heeft uitgegeven. Domeinhouders, CA's en het publiek beschikken hiermee over een mechanisme om de vertrouwde certificaten die ze zien, te registreren in openbaar verifieerbare, fraudebestendige logboeken op basis van toevoegingen. In het geval van CA's geldt dit ook voor de certificaten die zij afgeven. De certificaten in deze logboeken kunnen door iedereen worden gecontroleerd om na te gaan of de informatie correct, nauwkeurig en gemachtigd is.

De eerste versie van CT werd opgegeven in een experimentele IETF-RFC, namelijk RFC 6962. Tijdens de ontwikkeling van CT heeft Google een aantal opensource-tools beschikbaar gesteld, waaronder een opensource-logboekserver voor het vastleggen van certificaten, en tools voor het maken van CT-logboeken. Daarnaast vereist Google Chrome dat sommige certificaten openbaar moeten worden gemaakt, zoals EV-certificaten (Extended Validation) of certificaten die zijn uitgegeven door CA's die in het verleden ten onrechte certificaten hebben uitgegeven. Vanaf 2018 vereist Chrome dat alle nieuwe openbaar vertrouwde certificaten openbaar worden gemaakt.

Als websitebeheerder kunt u CT gebruiken om te detecteren of er ongemachtigde certificaten zijn uitgegeven voor uw website. Er zijn gratis tools die dit eenvoudig maken, zoals Certificaattransparantierapport van Google, Certificate Search of tools van Facebook. Zelfs als u geen certificaattransparantie gebruikt, kijkt een aantal browsers nu regelmatig naar de certificaattransparantie om te waarborgen dat de CA's die uw gebruikers vertrouwen voor het bezoeken van uw website, voldoen aan branchevereisten en best practices, zodat het risico op bedrieglijke certificaten wordt beperkt.

Het gebruik van HTTPS vergroten

Zoals beschreven bij Versleuteling tussen de gebruiker en Google Front End, werken we er hard aan om te zorgen dat onze sites en services standaard moderne HTTPS bieden. Ons doel is om 100% versleuteling te bereiken voor onze producten en services. Daarom publiceren we een jaarlijks HTTPS-transparantierapport waarin u de vorderingen op dit gebied kunt volgen voor alle property's, inclusief Google Cloud. We blijven werken aan het oplossen van de technische belemmeringen die het bemoeilijken om versleuteling in een aantal van onze producten te ondersteunen, zoals oplossingen voor browsers of andere clients die geen ondersteuning bieden voor HTTP Strict Transport Security (HSTS)18. We gebruiken HSTS voor een aantal van onze sites, waaronder de homepage van google.com, zodat gebruikers alleen via HTTPS verbinding kunnen maken met een server.

We weten dat de rest van het internet bezig is om een overstap te maken naar HTTPS. We proberen deze overstap op de volgende manieren te ondersteunen:

In 2016 zijn we begonnen met het publiceren van statistieken over 'HTTPS-gebruik op internet' voor de Top 100 niet-Google-sites op internet. Met deze statistieken proberen we het bewustzijn te vergroten en het internet veiliger te maken voor alle gebruikers. In oktober 2017 heeft Chrome zijn financiële steun voor Let's Encrypt officieel opnieuw toegezegd als Platina-sponsor.

Het gebruik van beveiligde SMTP vergroten: Gmail-indicatoren

De meeste e-mail wordt uitgewisseld met behulp van het Simple Mail Transfer Protocol (SMTP), dat standaard e-mail stuurt zonder versleuteling te gebruiken. De e-mailprovider moet beveiligingsmaatregelen zoals TLS implementeren om een e-mail te versleutelen.

Zoals besproken bij Versleuteling tussen de gebruiker en Google Front End, gebruikt Gmail standaard TLS. Bovendien wordt bij TLS als vereiste in Gmail beschreven hoe Gmail-beheerders het gebruik van TLS-beveiliging voor inkomende en uitgaande e-mail kunnen afdwingen. Vergelijkbaar met de inspanningen van Google op het gebied van HTTPS-transparantie stelt Gmail gegevens beschikbaar over TLS-gebruik voor inkomende e-mails in Gmail. Deze gegevens worden gepresenteerd in ons Transparantierapport voor veiligere e-mails.

Google speelt in samenwerking met de IETF en andere belangrijke spelers in de sector een vooraanstaande rol bij het ontwikkelen van SMTP STS. SMTP STS is vergelijkbaar met HSTS voor HTTPS en dwingt het gebruik van SMTP via uitsluitend versleutelde kanalen af.

API's van Chrome

In februari 2015 heeft Chrome aangekondigd dat krachtige nieuwe functies alleen beschikbaar worden voor beveiligde bronnen19. Zulke functies omvatten de verwerking van privé-informatie en toegang tot sensoren op het apparaat van een gebruiker. We beëindigen het gebruik van deze functies voor niet-beveiligde bronnen, te beginnen met geolocatie in Chrome 50.

Constante innovaties op het gebied van versleuteling van 'data in transit'

Gebruikerservaring bij beveiliging in Chrome

Google Chrome is marktleider in het gebruik van de eigen UI om beveiligingsinformatie weer te geven op een manier die gebruikers snel inzicht geeft in de veiligheid van hun verbinding met een site. Met deze informatie kunnen gebruikers weloverwogen beslissingen nemen over wanneer en hoe zij hun gegevens delen. Chrome voert uitgebreid gebruikersonderzoek uit, waarvan de resultaten worden gedeeld in door andere wetenschappers geredigeerde artikelen.

Chrome heeft aangekondigd dat het tegen het einde van 2017 alle HTTP-verbindingen als niet-beveiligd markeert om gebruikers verder te beschermen. Vanaf Chrome 56 zien gebruikers standaard een waarschuwing als een HTTP-pagina een formulier met wachtwoord- of creditcardvelden bevat. Vanaf Chrome 62 wordt er een waarschuwing weergegeven wanneer een gebruiker gegevens invoert op een HTTP-pagina en voor alle HTTP-pagina's die een gebruiker bezoekt in de incognitomodus. Uiteindelijk geeft Chrome een waarschuwing weer voor alle pagina's die via HTTP worden geleverd.

Als u wilt zien hoe bepaalde configuraties worden getoond aan gebruikers in Chrome, kunt u de BadSSL-tool gebruiken.

Sleuteltransparantie

De algemene acceptatie van berichtversleuteling wordt in hoge mate belemmerd door de moeilijkheid van het uitwisselen van openbare sleutels: hoe kan ik op betrouwbare wijze de openbare sleutel vinden voor een nieuwe gebruiker met wie ik communiceer? Google heeft in januari 2017 Sleuteltransparantie aangekondigd om dit probleem op te lossen. Dit is een open framework dat een generieke, beveiligde en controleerbare manier biedt om openbare sleutels te distribueren. Dankzij dit framework hoeven gebruikers zelf geen handmatige sleutelverificatie uit te voeren. Sleuteltransparantie is met name gericht op de distributie van openbare sleutels van gebruikers tijdens communicatie, bijvoorbeeld bij E2E- en OpenPGP-e-mailversleuteling. Het ontwerp van sleuteltransparantie is een nieuwe benadering van sleutelherstel en -distributie en is gebaseerd op inzichten uit certificaattransparantie en CONIKS.

De ontwikkeling van sleuteltransparantie is open source en wordt geïmplementeerd met behulp van een grootschalige Merkle-structuur. Met Sleuteltransparantieverificatie kunnen accounteigenaren zien welke sleutels aan hun accounts zijn gekoppeld en hoelang een account al actief en stabiel is. Het langetermijndoel van de sleuteltransparantiefunctie van Google is om iedereen in staat te stellen een server met sleuteltransparantie uit te voeren en deze eenvoudig te integreren in een onbeperkt aantal apps.

Postkwantum-cryptografie

Google wil graag marktleider blijven op het gebied van versleuteling van 'data in transit'. Daarom zijn we begonnen met postkwantum-cryptografie. Met dergelijke cryptografie kunnen we bestaande versleutelingsalgoritmen die kwetsbaar zijn voor efficiënte kwantumaanvallen, vervangen door postkwantum-kandidaten die naar verwachting robuuster zijn. In juli 2016 maakten we bekend dat we een experiment hebben uitgevoerd om de haalbaarheid van het gebruik van een dergelijk algoritme te bepalen. Dit experiment is uitgevoerd met het New Hope-algoritme voor postkwantum-cryptografie in de Chrome-versie voor ontwikkelaars. Naast dit werk hebben onderzoekers van Google ook artikelen gepubliceerd over andere praktische postkwantum-protocollen voor sleuteluitwisseling.

Bijlage

Lees meer over Google Cloud Security, zoals ons overzicht van het infrastructuurbeveiligingsontwerp, de naleving van Google Cloud en het openbare SOC 3-auditrapport.

Voetnoten

1 Partneroplossingen omvatten zowel oplossingen die worden aangeboden in Cloud Launcher als producten die zijn ontworpen in samenwerking met partners, zoals Cloud Dataprep.
2 U kunt deze versleuteling nog steeds uitschakelen, bijvoorbeeld voor HTTP-toegang tot Google Cloud Storage-buckets.
3 Communicatie van VM's naar services die niet worden beschermd op laag 7, wordt nog steeds beschermd op laag 3 en 4.
4 TLS 1.3 is nog niet definitief. De conceptversie is alleen voor bepaalde Google-domeinen, zoals Gmail, geïmplementeerd voor testen.
5 Google ondersteunt TLS 1.0 voor browsers die nog steeds deze versie van het protocol gebruiken. Houd er rekening mee dat sites van Google die creditcardgegevens verwerken, vanaf juli 2018 niet langer TLS 1.0 ondersteunen. Vanaf dan is de beëindiging van TLS 1.0 vereist voor naleving van de Payment Card Industry (PCI).
6 Zie [https://www.chromium.org/quic](https://www.chromium.org/quic) voor meer informatie over QUIC.
7, 8, 9 Voor compatibiliteit met een aantal verouderde besturingssystemen ondersteunen we 3DES, SHA1 en MD5.
10In het geval van geschakelde certificaten wordt de CA tijdens de transitie vertrouwd.
11 Dit kan een sessieticket ([RFC 5077](https://tools.ietf.org/html/rfc5077)) of een sessie-ID ([RFC 5246](https://tools.ietf.org/html/rfc5246)) zijn.
12 Het besturingsvlak is het deel van het netwerk dat signaleringsverkeer verzorgt en verantwoordelijk is voor routing.
13 In het verleden werden andere protocollen gebruikt, maar het gebruik daarvan is nu beëindigd. Minder dan 1% van de taken gebruikt deze oudere protocollen.
14 Datagram TLS (DTLS) biedt beveiliging voor op datagram gebaseerde apps. Deze kunnen dankzij DTLS communiceren zonder risico op afluisteren of manipulatie.
15Internet Key Exchange (IKE) is het protocol dat wordt gebruikt om een beveiligingskoppeling in de IPsec-protocolsuite in te stellen.
16 HMAC-SHA-1 wordt niet verbroken door een [SHA-1-botsing](https://shattered.io/), zoals de SHAttered-botsing die Google-onderzoekers vonden.
17 Voor G Suite Enterprise wordt dit niet in de UI weergegeven. Domeinbeheerders kunnen de gegevens voor hun domein onderzoeken met [Zoeken in e-maillogboeken](https://support.google.com/a/answer/2604578).
18 HTTP Strict Transport Security (HSTS) is een mechanisme waarmee websites zich alleen via beveiligde verbindingen kunnen aanmelden en/of waarmee gebruikers hun gebruikersagent(s) alleen via beveiligde verbindingen met bepaalde sites kunnen laten communiceren.
19 Beveiligde bronnen zijn verbindingen die overeenkomen met bepaalde [patronen](https://www.chromium.org/Home/chromium-security/prefer-secure-origins-for-powerful-new-features) van schema's, hosts of poorten.