Beveiligingsgids voor Hadoop-migratie

Cloud Dataproc en Google Cloud Platform (GCP) bevatten verschillende functies die kunnen helpen bij het beveiligen van uw gegevens. In deze gids wordt uitgelegd hoe Hadoop-beveiliging werkt en hoe dit zich vertaalt naar GCP. U vindt hier ook richtlijnen voor het ontwerpen van beveiliging bij implementatie op GCP.

Overzicht

Het gebruikelijke beveiligingsmodel en -mechanisme voor een lokale Hadoop-implementatie wijken af van het beveiligingsmodel en -mechanisme van de cloud. Weten hoe beveiliging van Hadoop werkt kan u helpen bij het ontwerpen van beveiliging wanneer u op GCP implementeert.

U kunt op twee manieren Hadoop op GCP implementeren: als door Google beheerde clusters (Cloud Dataproc) of als door gebruikers beheerde clusters (Hadoop op Compute Engine). De meeste content en technische richtlijnen in deze handleiding zijn van toepassing op beide vormen van implementatie. In deze gids wordt de term Cloud Dataproc/Hadoop gebruikt voor verwijzingen naar concepten of procedures die van toepassing zijn op beide implementatietypen. Er worden enkele gevallen besproken waar implementatie naar Cloud Dataproc afwijkt van implementatie naar Hadoop op Compute Engine.

Gebruikelijke Hadoop-beveiliging op locatie

Het volgende diagram toont een gebruikelijke Hadoop-infrastructuur op locatie en hoe deze wordt beveiligd. U ziet de interactie van de Hadoop-basiscomponenten met elkaar en met systemen voor gebruikersbeheer.

Hadoop-infrastructuur met afzonderlijke vakken voor gebruikersruimte, beveiligingsomtrek en beveiligde Hadoop

In zijn geheel is Hadoop-beveiliging gebaseerd op deze vier pijlers:

  • Verificatie gaat via Kerberos dat is geïntegreerd met LDAP of Active Directory.
  • Autorisatie gaat via HDFS en beveiligingsproducten zoals Apache Sentry of Apache Ranger, die ervoor zorgen dat gebruikers de juiste toegang tot Hadoop-resources hebben.
  • Versleuteling gaat via netwerk- en HDFS-versleuteling die samen gegevens beveiligen, zowel tijdens verzending als op de server.
  • Controle gaat via producten van een leverancier, zoals Cloudera Navigator.

Gezien vanuit het gebruikersaccount heeft Hadoop zijn eigen gebruikers- en groepsstructuur om zowel identiteiten te beheren als daemons uit te voeren. Voorbeelden hiervan zijn de Hadoop HDFS- en YARN-daemons, uitgevoerd als Unix-gebruikers hdfs en yarn, zoals wordt uitgelegd in Hadoop in Secure Mode (Hadoop in de veilige modus).

Hadoop-gebruikers worden meestal toegewezen vanuit Linux-systeemgebruikers of Active Directory/LDAP-gebruikers. Gebruikers en groepen van Active Directory worden gesynchroniseerd met tools zoals Centrify of RedHat SSSD.

Verificatie op locatie in Hadoop

Een veilig systeem vereist dat gebruikers en services zich identificeren. De Hadoop-beveiligingsmodus gebruikt Kerberos voor verificatie. De meeste Hadoop-componenten zijn ontworpen voor verificatie door Kerberos. Kerberos wordt meestal geïmplementeerd in bedrijfsverificatiesystemen zoals Active Directory of LDAP-compatibele systemen.

Kerberos-principals

Een gebruiker wordt in Kerberos een principal genoemd. In een Hadoop-implementatie zijn er gebruiker- en service-principals. Gebruikerprincipals worden meestal gesynchroniseerd vanaf Active Directory of andere gebruikersbeheersystemen naar een sleuteldistributiecentrum (KDC). Eén gebruikerprincipal vertegenwoordigt één menselijke gebruiker. Een service-principal is uniek voor een service per server, dus elke service op elke server heeft één unieke principal die de server vertegenwoordigt.

Keytab-bestanden

Een keytab-bestand bevat Kerberos-principals en hun sleutels. Gebruikers en services kunnen keytabs gebruiken voor verificatie bij Hadoop-services zonder interactieve tools te gebruiken en wachtwoorden in te voeren. Hadoop maakt service-principals voor elke service op elk knooppunt. Deze principals worden opgeslagen in keytab-bestanden op Hadoop-knooppunten.

SPNEGO

Als u een Kerberized-cluster opent met een webbrowser, moet de browser weten hoe Kerberos-sleutels moeten worden doorgegeven. Hiervoor wordt het Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) gebruikt, een manier om Kerberos in web-apps te gebruiken.

Integratie

Hadoop integreert niet alleen met Kerberos voor gebruikersverificatie, maar ook voor serviceverificatie. Elke Hadoop-service op elk knooppunt heeft een eigen Kerberos-principal die voor verificatie wordt gebruikt. Services hebben meestal keytab-bestanden die op de server zijn opgeslagen en een willekeurig wachtwoord bevatten.

Om met services te kunnen communiceren, moeten menselijke gebruikers hun Kerberos-ticket meestal verkrijgen via de opdracht kinit of Centrify of SSSD.

Autorisatie op locatie in Hadoop

Nadat een identiteit is gevalideerd, controleert het autorisatiesysteem welk type toegang de gebruiker of service heeft. Op Hadoop worden enkele open source-projecten zoals Apache Sentry en Apache Ranger voor het verlenen van autorisatie gebruikt.

Apache Sentry en Apache Ranger

Apache Sentry en Apache Ranger zijn algemene autorisatiemechanismen die in Hadoop-clusters worden gebruikt. Componenten op Hadoop implementeren hun eigen plug-ins in Sentry of Ranger om aan te geven hoe ze zich moeten gedragen wanneer Sentry of Ranger de toegang voor een identiteit bevestigt of weigert. Sentry en Ranger zijn afhankelijk van verificatiesystemen zoals Kerberos, LDAP of AD. Het groepstoewijzingsmechanisme in Hadoop zorgt ervoor dat Sentry of Ranger dezelfde groepstoewijzingen ziet als de andere componenten van het Hadoop-ecosysteem zien.

HDFS-machtigingen en ACL

HDFS gebruikt een POSIX-achtig machtigingssysteem met een toegangscontrolelijst (ACL) om te bepalen of gebruikers toegang hebben tot bestanden. Bestanden en mappen zijn allemaal aan een eigenaar en een groep gekoppeld. De structuur heeft een hoofdmap die wordt beheerd door een supergebruiker. Ieder niveau van de structuur kan een eigen versleuteling, eigenaar, machtiging en uitgebreide ACL (facl) hebben.

Zoals te zien is in het volgende diagram, worden machtigingen gewoonlijk verleend op mapniveau aan specifieke groepen op basis van hun toegangsbehoeften. Toegangspatronen worden geïdentificeerd als verschillende rollen en worden toegewezen aan Active Directory-groepen. Objecten die behoren tot een enkele dataset bevinden zich over het algemeen op de laag met machtigingen voor een specifieke groep, met verschillende mappen voor verschillende gegevenscategorieën.

POSIX-achtige mapstructuur van HDFS

De map stg is bijvoorbeeld het verzamelgebied voor financiële gegevens. De map stg heeft lees- en schrijfmachtigingen voor de groep fin-loader. Vanuit dit verzamelgebied heeft een andere app-accountgroep, fin-etl, die ETL-pipelines vertegenwoordigt, alleen-lezen toegang tot deze map. ETL-pipelines verwerken gegevens en slaan ze op in de map app die moet worden geleverd. Om dit toegangspatroon in te schakelen, heeft de map app lees-/schrijftoegang voor de groep fin-etl (de identiteit die wordt gebruikt om de ETL-gegevens te schrijven), en alleen-lezen toegang voor de groep fin-reader (die de resulterende gegevens verbruikt).

Versleuteling op locatie met Hadoop

Hadoop biedt manieren om inactieve gegevens en gegevens tijdens de overdracht te versleutelen. Als u inactieve gegevens wilt versleutelen, kunt u HDFS versleutelen met behulp van Java-versleuteling of versleutelingsoplossingen van leveranciers. HDFS ondersteunt versleutelingszones waarmee verschillende bestanden met verschillende sleutels versleuteld kunnen worden. Elke versleutelingszone is gekoppeld aan een enkele zonesleutel die is opgegeven bij het maken van de zone.

Elk bestand in een versleutelingszone heeft een unieke sleutel voor gegevensversleuteling (DEK). DEK's worden nooit rechtstreeks afgehandeld door HDFS. In plaats daarvan verwerkt HDFS alleen een versleutelde gegevensversleutelingssleutel (EDEK). Clients ontsleutelen een EDEK en gebruiken vervolgens de volgende DEK om gegevens te lezen en te schrijven. HDFS-gegevensknooppunten zien gewoon een stroom van versleutelde bytes.

Gegevensoverdracht tussen Hadoop-knooppunten kan worden versleuteld met behulp van Transport Layer Security (TLS). TLS biedt versleuteling en verificatie in de communicatie tussen twee componenten van Hadoop. Gewoonlijk zou Hadoop interne, door CA ondertekende, certificaten voor TLS tussen componenten gebruiken.

Hadoop-controle op locatie

Controle is een belangrijk onderdeel van beveiliging. Met controle kunt u verdachte activiteiten vinden en krijgt u een overzicht van de personen die toegang tot resources hebben gehad. Cloudera Navigator en andere tools van derden worden meestal gebruikt voor gegevensbeheer, zoals controletracering op Hadoop. Deze tools bieden inzicht in en controle over de gegevens in Hadoop-datastores en over de berekeningen die op die gegevens zijn uitgevoerd. Gegevenscontrole kan een volledig en onveranderlijk record van alle activiteiten binnen een systeem vastleggen.

Hadoop op GCP

In een traditionele Hadoop-omgeving op locatie worden de vier pijlers van Hadoop-beveiliging (verificatie, autorisatie, versleuteling en controle) geïntegreerd en verwerkt door verschillende componenten. Op GCP worden ze door verschillende GCP-componenten buiten Cloud Dataproc en Hadoop op Compute Engine verwerkt.

U kunt GCP-resources met behulp van de GCP-console, een webinterface, beheren. U kunt ook de opdrachtregeltool gcloud gebruiken, wat sneller en handiger kan zijn als u vertrouwd bent met het werken op opdrachtregels. U kunt gcloud-opdrachten uitvoeren door de Cloud SDK op uw lokale computer te installeren of door een instantie van Cloud Shell te gebruiken.

GCP-verificatie in Hadoop

Er zijn twee soorten Google-identiteiten binnen GCP: serviceaccounts en gebruikersaccounts. De meeste Google API's vereisen verificatie met een Google-identiteit. Een beperkt aantal GCP API's werkt zonder verificatie (met behulp van API-sleutels), maar we raden aan om alle API's te gebruiken met verificatie van serviceaccounts.

Serviceaccounts gebruiken privésleutels om identiteiten vast te stellen. Gebruikersaccounts gebruiken het OAUTH 2.0-protocol om eindgebruikers te verifiëren. Zie Verificatieoverzicht voor meer informatie.

GCP-autorisatie in Hadoop

In GCP kunt u op meerdere manieren opgeven welke machtigingen een geverifieerde identiteit voor een reeks resources heeft.

Cloud IAM

GCP biedt identiteits- en toegangsbeheer in de cloud (Cloud IAM), waarmee u de toegangscontrole kunt beheren door te definiëren welke gebruikers (leden) welke toegang (rol) hebben tot welke resource.

Met Cloud IAM kunt u toegang verlenen tot GCP-resources en ongewenste toegang tot andere resources voorkomen. Met Cloud IAM kunt u het beveiligingsprincipe van het laagste recht toepassen, zodat u alleen de minimaal benodigde toegang aan uw resources toekent.

Serviceaccounts

Een serviceaccount is een speciaal type Google-account dat bij uw app of een virtuele machine (VM) hoort, in plaats van bij een individuele eindgebruiker. Apps kunnen serviceaccountgegevens gebruiken om zichzelf te verifiëren bij andere Cloud API's. Bovendien kunt u firewallregels maken die verkeer van en naar instanties toestaan of weigeren op basis van het serviceaccount dat aan elke instantie is toegewezen.

Cloud Dataproc-clusters zijn boven op de VM's van Compute Engine gebouwd. Wanneer u een custom serviceaccount toewijst bij het maken van een Cloud Dataproc-cluster, wordt dat serviceaccount aan alle VM's in uw cluster toegewezen. Dit geeft uw cluster gedetailleerde toegang tot en controle over GCP-resources. Als u geen serviceaccount opgeeft, gebruiken VM's van Cloud Dataproc het standaard door Google beheerde Compute Engine-serviceaccount. Dit account heeft standaard de brede rol van projectbewerker en daarmee heel veel verschillende machtigingen. We raden af om het standaard serviceaccount te gebruiken om een Cloud Dataproc-cluster in een productieomgeving te maken.

Machtigingen voor serviceaccount

Wanneer u een custom serviceaccount toewijst aan een Cloud Dataproc-/Hadoop-cluster, wordt het toegangsniveau van dat serviceaccount bepaald door de combinatie van toegangsbereiken die zijn toegewezen aan de VM-instanties van het cluster en de Cloud IAM-rollen die zijn toegewezen aan uw serviceaccount. Als u een instantie wilt instellen met uw custom serviceaccount, moet u zowel toegangsbereiken als Cloud IAM-rollen configureren. In wezen werken deze mechanismen als volgt samen:

  • Toegangsbereiken machtigen de toegang van een instantie.
  • Cloud IAM beperkt die toegang tot de rollen die zijn toegewezen aan het serviceaccount dat de instantie gebruikt.
  • De machtigingen op het kruispunt van toegangsbereiken en Cloud IAM-rollen zijn de uiteindelijke machtigingen van de instantie.

Wanneer u een Cloud Dataproc-cluster of Compute Engine-instantie maakt in de GCP-console, selecteert u het toegangsbereik van de instantie:

Screenshot van opties voor het instellen van het bereik in de GCP-console

Een Cloud Dataproc-cluster of Compute Engine-instantie heeft een reeks toegangsbereiken die zijn gedefinieerd voor gebruik met de instelling Standaardtoegang toestaan:

Lijst met gedefinieerde toegangsbereiken

Er zijn veel toegangsbereiken waaruit u kunt kiezen. We raden u aan bij het maken van een nieuwe VM-instantie of een nieuw cluster het toegangsbereik Volledige toegang tot alle cloud-API's (in de console) of https://www.googleapis.com/auth/cloud-platform in te stellen (als u de opdrachtregeltool gcloud gebruikt). Deze bereiken machtigen de toegang tot alle GCP-services. Nadat u het bereik heeft ingesteld, raden we u aan die toegang vervolgens te beperken door Cloud IAM-rollen toe te wijzen aan het clusterserviceaccount.

Het account kan ondanks het GCP-toegangsbereik buiten deze rollen geen acties uitvoeren. In de documentatie van de serviceaccountmachtigingen vindt u meer informatie.

Cloud IAM vergeleken met Apache Sentry en Apache Ranger

Cloud IAM speelt ongeveer dezelfde rol als Apache Sentry en Apache Ranger. Cloud IAM definieert toegang op basis van rollen. Toegang tot andere GCP-componenten is in deze rollen gedefinieerd en is gekoppeld aan serviceaccounts. Dit betekent dat alle instanties die hetzelfde serviceaccount gebruiken, dezelfde toegang hebben tot andere GCP-resources. Iedereen die toegang heeft tot deze instanties, heeft ook dezelfde toegang tot deze GCP-resources als het serviceaccount.

Cloud Dataproc-clusters en Compute Engine-instanties hebben geen mechanisme om Google-gebruikers en -groepen toe te wijzen aan Linux-gebruikers en -groepen. U kunt echter wel Linux-gebruikers en -groepen maken. In het Cloud Dataproc-cluster of in Compute Engine-VM's werken HDFS-machtigingen en Hadoop-gebruikers- en groepstoewijzing nog steeds. Deze toewijzing kan worden gebruikt om de toegang tot HDFS te beperken of om resourcetoewijzing af te dwingen met behulp van een YARN-wachtrij.

Wanneer apps op een Cloud Dataproc-cluster of Compute Engine-VM toegang moeten hebben tot externe resources, zoals Cloud Storage of BigQuery, worden die apps geverifieerd als de identiteit van het serviceaccount dat u heeft toegewezen aan de VM's in het cluster. Vervolgens gebruikt u Cloud IAM om het custom serviceaccount van uw cluster het minimale toegangsniveau te verlenen dat uw app nodig heeft.

Cloud Storage-machtigingen

Cloud Dataproc gebruikt Cloud Storage voor zijn opslagsysteem. Cloud Dataproc biedt ook een lokaal HDFS-systeem, maar HDFS is niet beschikbaar als het Cloud Dataproc-cluster wordt verwijderd. Als de app niet strikt afhankelijk is van HDFS, kunt u het beste cloudopslag gebruiken om alle functies van GCP te benutten.

Cloud Storage heeft geen opslaghiërarchieën. De mapstructuur simuleert de structuur van een bestandssysteem. Het heeft ook geen POSIX-achtige machtigingen. Toegangsbeheer door Cloud IAM-gebruikersaccounts en serviceaccounts kan op bucketniveau worden ingesteld. Er worden geen machtigingen afgedwongen die op Linux-gebruikers zijn gebaseerd.

GCP-versleuteling in Hadoop

Op een paar kleine uitzonderingen na versleutelen GCP-services klantencontent op de server en tijdens verzending met verschillende versleutelingsmethoden. Het versleutelen gebeurt automatisch en hiervoor is geen actie van de klant vereist.

Zo worden bijvoorbeeld alle nieuwe gegevens op persistente schijven versleuteld volgens de norm voor geavanceerde 256-bits versleuteling (AES-256) en wordt elke versleutelingssleutel weer versleuteld met een regelmatig vernieuwde set hoofdsleutels. GCP gebruikt hetzelfde beleid voor versleuteling en sleutelbeheer, dezelfde cryptografische bibliotheken en dezelfde vertrouwensbasis als voor veel productieservices van Google, zoals Gmail en de eigen bedrijfsgegevens van Google.

Omdat versleuteling een standaardfunctie van GCP is (in tegenstelling tot de meeste Hadoop-implementaties op locatie), hoeft u zich geen zorgen te maken over het implementeren van versleuteling, tenzij u uw eigen versleutelingssleutel wilt gebruiken. GCP biedt ook een door de klant beheerde oplossing voor versleutelingssleutels en een door de klant geleverde oplossing voor versleutelingssleutels. Als u wilt, kunt u zelf versleutelingssleutels beheren of versleutelingssleutels op locatie opslaan.

Zie versleuteling van inactieve gegevens en versleuteling tijdens de overdracht voor meer informatie.

GCP-controle in Hadoop

Cloud-controlelogboek kan een paar soorten logboeken bijhouden voor elk project en elke organisatie. GCP-services schrijven controlelogboekitems naar deze logboeken zodat u weet wie wat waar en wanneer deed binnen uw GCP-projecten.

Raadpleeg de documentatie bij Cloud-controlelogboek voor meer informatie over controlelogboeken en services die controlelogboeken schrijven.

Migratieproces

Volg de procedure in dit gedeelte om Hadoop veilig en efficiënt uit te voeren op GCP.

In dit gedeelte gaan we ervan uit dat u uw GCP-omgeving heeft ingesteld. Hieronder valt ook het maken van gebruikers en groepen in G Suite. Deze gebruikers en groepen worden handmatig beheerd of gesynchroniseerd met Active Directory. Bovendien heeft u alles zo geconfigureerd dat GCP volledig functioneel is wat betreft het verifiëren van gebruikers.

Bepaal wie identiteiten gaat beheren

De meeste Google-klanten gebruiken Cloud Identity voor het beheer van identiteiten. Maar sommige klanten beheren hun bedrijfsidentiteiten los van GCP-identiteiten. In dat geval bepalen hun POSIX- en SSH-machtigingen hun toegang als eindgebruiker tot cloudresources.

Als u een onafhankelijk identiteitssysteem heeft, gaat u eerst GCP-serviceaccountsleutels maken en deze downloaden. Vervolgens kunt u uw lokale POSIX- en SSH-beveiligingsmodel verbinden met het GCP-model door geschikte toegangsrechten in POSIX-stijl toe te kennen aan de gedownloade sleutelbestanden van het serviceaccount. U verleent of weigert uw lokale identiteiten toegang tot deze sleutelbestanden.

Als u deze route volgt, is de controleerbaarheid in handen van uw eigen identiteitsbeheersystemen. Als u een audittrail wilt opgeven, kunt u de SSH-logboeken (die de sleutelbestanden van de serviceaccounts gebruiken) van gebruikersgegevens op edge-knooppunten gebruiken. U kunt ook voor een zwaarder en expliciet keystore-mechanisme kiezen om gebruikersgegevens voor serviceaccounts op te halen. In dat geval wordt de 'nabootsing van de identiteit van het serviceaccount' in het controlelogboek op de keystore-laag geregistreerd.

Bepaal of u één of meerdere gegevensprojecten wilt gebruiken

Als uw organisatie veel gegevens heeft, betekent dit dat u de gegevens in verschillende Cloud Storage-buckets moet opsplitsen. U moet ook nadenken over de manier waarop u deze gegevensbuckets over uw projecten wilt verdelen. U zou in de verleiding kunnen komen om een kleine hoeveelheid gegevens over te zetten wanneer u aan de slag gaat op GCP en in de loop van de tijd steeds meer gegevens te verplaatsen naarmate productietaken en apps zich verplaatsen.

Het kan handig lijken om al uw gegevensbuckets onder één project te houden, maar dat is vaak geen goede aanpak. Om de toegang tot de gegevens te beheren, gebruikt u een afgevlakte mapstructuur met IAM-rollen voor buckets. Naarmate het aantal buckets groeit, kan het beheer omslachtig worden.

Als alternatief kunt u gegevens opslaan in meerdere projecten die elk speciaal zijn bedoeld voor verschillende afdelingen: een project voor de financiële afdeling, een ander voor de juridische groep, enzovoort. In dit geval beheert elke groep onafhankelijk zijn eigen machtigingen.

Tijdens de gegevensverwerking kan het nodig zijn om ad hoc-buckets te openen of te maken. De verwerking kan worden opgesplitst over vertrouwensgrenzen heen, zoals in het geval van datawetenschappers die toegang hebben tot gegevens die worden geproduceerd door een proces dat ze niet bezitten.

Het volgende diagram toont een gebruikelijke organisatie van gegevens in Cloud Storage onder een enkel gegevensproject en onder meerdere gegevensprojecten.

Typische opslagopties, in één project en in meerdere projecten

Dit zijn de belangrijkste aandachtspunten bij het bepalen van de beste aanpak voor uw organisatie:

Met één gegevensproject:

  • Het beheer van alle buckets is eenvoudig, zolang er een klein aantal buckets is.
  • Het verlenen van machtigingen wordt voornamelijk gedaan door leden van de beheerdersgroep.

Met meerdere gegevensprojecten:

  • Het wordt gemakkelijker om beheerverantwoordelijkheden te delegeren aan projecteigenaren.
  • Deze aanpak is handig voor organisaties met verschillende processen voor het verlenen van machtigingen. Het proces voor het verlenen van machtigingen kan voor projecten van de marketingafdeling bijvoorbeeld anders zijn dan voor projecten van de juridische afdeling.

Identificeer apps en maak serviceaccounts

Wanneer clusters van Cloud Dataproc/Hadoop samenwerken met andere GCP-resources, zoals met cloudopslag, moet u alle apps identificeren die worden uitgevoerd op Cloud Dataproc/Hadoop en bepalen welke toegang ze nodig hebben. Stel, er is een ETL-taak is die de bucket financial-ca vult met financiële gegevens in Californië. Deze ETL-taak heeft lees- en schrijftoegang tot de bucket nodig. Nadat u de apps heeft geïdentificeerd die Hadoop gebruiken, kunt u serviceaccounts voor al deze apps maken.

Deze toegang heeft geen invloed op Linux-gebruikers binnen het Cloud Dataproc-cluster of Hadoop op Compute Engine.

Zie Serviceaccounts maken en beheren voor meer informatie over serviceaccounts.

Verleen machtigingen aan serviceaccounts

Wanneer u weet welke toegang elke app moet hebben tot verschillende Cloud Storage-buckets, kunt u die machtigingen instellen voor de relevante app-serviceaccounts. Als uw apps ook toegang moeten hebben tot andere GCP-componenten, zoals BigQuery of Cloud Bigtable, kunt u ook machtigingen voor deze componenten verlenen met behulp van serviceaccounts.

U kunt bijvoorbeeld operation-ca-etl als ETL-app opgeven om operationele rapporten te genereren door marketing- en verkoopgegevens uit Californië samen te voegen en deze te machtigen om rapporten naar de gegevensbucket van de financiële afdeling te schrijven. Vervolgens kunt u de marketing-report-ca- en sales-report-ca-app zo instellen dat elke app lees- en schrijftoegang heeft tot zijn eigen afdeling. Dit wordt in het volgende diagram geïllustreerd.

Machtigingsconfiguratie voor serviceaccounts

Houd u aan het principe van minimale rechten. Volgens dit principe geeft u aan elke gebruiker of elk serviceaccount alleen de minimale rechten die nodig zijn voor het uitvoeren van taken. GCP bevat geoptimaliseerde standaardmachtigingen om gebruikersgemak te bieden en de configuratietijd te verkorten. Als u Hadoop-infrastructuren wilt ontwerpen die grote kans hebben te slagen voor beveiligings- en nalevingscontroles, moet u beperkende machtigingen ontwerpen. Wanneer u in een vroeg stadium in die strategieën investeert en ze documenteert, krijgt u een veilige pipeline die aan de regels voldoet. Maar het is ook handig als u de architectuur moet herzien met beveiligings- en complianceteams.

Maak clusters

Nadat u de toegang heeft gepland en geconfigureerd, kunt u Cloud Dataproc-clusters of Hadoop op Compute Engine maken met de serviceaccounts die u heeft gemaakt. Elk cluster heeft toegang tot andere GCP-componenten op basis van de machtigingen die u aan dat serviceaccount heeft gegeven. Zorg ervoor dat u het juiste toegangsbereik geeft voor toegang tot GCP en vervolgens aanpast met toegang tot het serviceaccount. Als er zich ooit een toegangsprobleem voordoet, met name voor Hadoop op Compute Engine, moet u deze machtigingen controleren.

Gebruik deze gcloud-opdracht om een Cloud Dataproc-cluster met een specifiek serviceaccount te maken:

gcloud dataproc clusters create [CLUSTER_NAME] \
    --service-account=[SERVICE_ACCOUNT_NAME]@[PROJECT+_ID].iam.gserviceaccount.comn \
    --scopes=scope[, ...]

Om de volgende redenen kunt u het standaard Compute Engine-serviceaccount beter niet gebruiken:

  • Als meerdere clusters en Compute Engine-VM's het standaard Compute Engine-serviceaccount gebruiken, bemoeilijkt dit de controle.
  • De projectinstelling voor het standaard Compute Engine-serviceaccount kan variëren. Dit betekent dat het mogelijk meer rechten heeft dan uw cluster nodig heeft.
  • Wijzigingen in het standaard Compute Engine-serviceaccount kunnen onbedoeld uw clusters en de apps die daarin worden uitgevoerd, beïnvloeden of zelfs verbreken.

Overweeg Cloud IAM-machtigingen in te stellen voor elk cluster

Het plaatsen van veel clusters onder één project kan het beheren van die clusters vergemakkelijken, maar het is misschien niet de beste manier om de toegang tot deze clusters te beveiligen. Als u bijvoorbeeld cluster 1 en 2 in project A gebruikt, hebben sommige gebruikers mogelijk de juiste rechten om op cluster 1 te werken, maar misschien ook te veel machtigingen voor cluster 2. Of erger nog, ze hebben misschien toegang tot cluster 2, simpelweg omdat het in dat project zit, wanneer ze geen toegang zouden moeten hebben.

Wanneer projecten veel clusters bevatten, kan de toegang tot die clusters een warboel worden, zoals wordt geïllustreerd in de volgende afbeelding.

Toegang tot individuele clusters in één project

Als u in plaats daarvan soortgelijke clusters in kleinere projecten groepeert en vervolgens Cloud IAM afzonderlijk voor elk cluster configureert, heeft u een betere controle over toegang. Gebruikers hebben dan toegang tot de clusters die voor hen zijn bedoeld en geen toegang tot andere.

Toegang tot clusters gegroepeerd in afzonderlijke projecten

Beperk de toegang tot clusters

Het instellen van de toegang met behulp van serviceaccounts beveiligt de interacties tussen Cloud Dataproc/Hadoop en andere GCP-componenten. Dit biedt echter geen volledige controle over wie toegang heeft tot Cloud Dataproc/Hadoop. Een gebruiker in het cluster, die het IP-adres van de Cloud Dataproc/Hadoop-clusterknooppunten heeft, kan bijvoorbeeld SSH nog steeds gebruiken om er verbinding mee te maken (in sommige gevallen) of om taken ernaartoe te sturen. In de lokale omgeving heeft de systeembeheerder meestal subnetten, firewallregels, Linux-verificatie en andere strategieën om de toegang tot Hadoop-clusters te beperken.

Er zijn veel manieren om de toegang te beperken op het niveau van G Suite- of GCP-verificatie wanneer u Cloud Dataproc/Hadoop gebruikt op Compute Engine. Deze gids is echter gericht op toegang op het niveau van de GCP-componenten.

Beperk inloggen bij SSH met OS Login

Om in de lokale omgeving de verbinding van gebruikers met een Hadoop-knooppunt te beperken, moet u omtrektoegangsbeheer, SSH-toegang op Linux-niveau en sudoer-bestanden instellen.

Op GCP kunt u als volgt SSH-beperkingen op gebruikersniveau configureren voor verbinding met Compute Engine-instanties:

  1. Schakel de functie OS Login in voor uw project of voor afzonderlijke instanties.
  2. Geef de benodigde Cloud IAM-rollen aan uzelf, uw projectleden of uw organisatieleden.
  3. Voeg eventueel custom SSH-sleutels toe aan gebruikersaccounts voor uzelf, uw projectleden of organisatieleden. Als alternatief kan Compute Engine automatisch deze sleutels voor u genereren wanneer u verbinding maakt met instanties.

Nadat u OS Login heeft ingeschakeld op een of meer instanties in uw project, accepteren die instanties alleen verbindingen van gebruikersaccounts die de benodigde Cloud IAM-rollen in uw project of organisatie hebben.

U zou bijvoorbeeld als volgt uw gebruikers toegang kunnen verlenen:

  1. Wijs de noodzakelijke instantietoegangsrollen toe aan de gebruiker. Gebruikers moeten de volgende rollen hebben:

    • De rol iam.serviceAccountUser
    • Een van de volgende inlogrollen:

      • De rol compute.osLogin, die geen beheerdersmachtigingen verleent
      • De rol compute.osAdminLogin, die wel beheerdersmachtigingen verleent
  2. Als u een organisatiebeheerder bent die Google-identiteiten van buiten uw organisatie toegang tot uw instanties wilt geven, wijst u aan die externe identiteiten de rol compute.osLoginExternalUser toe op uw organisatieniveau. Vervolgens moet u die externe identiteiten ook de rol compute.osLogin of compute.osAdminLogin op uw project- of organisatieniveau geven.

Nadat u de benodigde rollen heeft geconfigureerd, maakt u verbinding met een instantie met behulp van Compute Engine-tools. Compute Engine genereert automatisch SSH-sleutels en koppelt deze aan uw gebruikersaccount.

Zie Toegang tot instanties beheren met behulp van OS Login voor meer informatie over de functie OS Login.

Beperk de netwerktoegang met firewallregels

Op GCP kunt u ook firewallregels maken die gebruikmaken van serviceaccounts om het inkomend of uitgaand verkeer te filteren. Deze aanpak kan bijzonder goed werken onder de volgende omstandigheden:

  • U heeft een breed scala aan gebruikers of apps die toegang tot Hadoop nodig hebben, wat betekent dat het maken van regels op basis van het IP-adres een uitdaging is.
  • U voert kortstondige Hadoop-clusters of client-VM's uit, zodat de IP-adressen vaak veranderen.

Door firewallregels te gebruiken in combinatie met serviceaccounts, kunt u de toegang tot een bepaald Cloud Dataproc/Hadoop-cluster instellen om alleen een bepaald serviceaccount toe te staan. Op die manier hebben alleen de VM's die als dat serviceaccount worden uitgevoerd, toegang tot het opgegeven niveau tot het cluster.

Het volgende diagram illustreert het gebruik van serviceaccounts om de toegang te beperken. dataproc-app-1 , dataproc-1 , dataproc-2 en app-1-client zijn allemaal serviceaccounts. Firewallregels zorgen dat dataproc-app-1 toegang kan krijgen tot dataproc-1 en dataproc-2 en dat clients die app-1-client gebruiken toegang hebben tot dataproc-1. Aan opslagzijde worden Cloud Storage-toegang en -machtigingen beperkt door Cloud Storage-machtigingen voor serviceaccounts in plaats van door firewallregels.

Serviceaccounts en firewallregels gebruiken om de toegang tot resources te beperken

Voor deze configuratie zijn de volgende firewallregels opgesteld:

Naam regel Instellingen
dp1 Doel: dataproc-1
Bron: [IP Range]
Bron-SA: dataproc-app-1
[Ports] toestaan
dp2 Doel: dataproc-2
Bron: [IP Range]
Bron-SA: dataproc-app-2
[Ports] toestaan
dp2-2 Doel: dataproc-2
Bron: [IP Range]
Bron-SA: dataproc-app-1
[Ports] toestaan
app-1-client Doel: dataproc-1
Bron: [IP Range]
Bron-SA: app-1-client
[Ports] toestaan

Zie Bron- en doelfiltering op serviceaccount voor meer informatie over het gebruik van firewallregels met serviceaccounts.

Controleer of er per ongeluk geopende firewallpoorten zijn

Het hebben van de juiste firewallregels is ook belangrijk voor het beschikbaar stellen van op het web gebaseerde gebruikersinterfaces die op het cluster worden uitgevoerd. Zorg ervoor dat u geen open firewallpoorten van internet heeft die verbinding maken met deze interfaces. Openstaande poorten en onjuist geconfigureerde firewallregels kunnen ongeautoriseerde gebruikers de mogelijkheid bieden om willekeurige code uit te voeren.

Apache Hadoop YARN biedt bijvoorbeeld REST API's die dezelfde poorten delen als de YARN-webinterfaces. Gebruikers die toegang hebben tot de YARN-webinterface kunnen standaard apps maken, taken verzenden en mogelijk Cloud Storage-bewerkingen uitvoeren.

Bekijk de netwerkconfiguraties van Dataproc en maak een SSH-tunnel om een veilige verbinding tot stand te brengen met het model van uw cluster. Zie Bron- en doelfiltering op serviceaccount(/vpc/docs/firewalls#serviceaccounts]{: track-type="solution" track-name="internalLink" track-metadata-position="body" } voor meer informatie over het gebruik van firewallregels met serviceaccounts.

Hoe zit het met clusters met meerdere tenants?

Over het algemeen is het een goede gewoonte om afzonderlijke Cloud Dataproc/Hadoop-clusters voor verschillende apps uit te voeren. Maar als u een cluster met meerdere tenants moet gebruiken en geen beveiligingsvereisten wilt schenden, kunt u Linux-gebruikers en -groepen in de Cloud Dataproc/Hadoop-clusters maken om autorisatie en resourcetoewijzing via een YARN-wachtrij te bieden. De verificatie moet door u worden geïmplementeerd omdat er geen directe toewijzing is tussen Google-gebruikers en Linux-gebruikers. Als u Kerberos op het cluster inschakelt, kan het verificatieniveau binnen het bereik van het cluster worden versterkt.

Soms gebruiken menselijke gebruikers, zoals een groep datawetenschappers, een Hadoop-cluster om gegevens te ontdekken en modellen te bouwen. In een dergelijke situatie zou het een goede keuze zijn om gebruikers die dezelfde toegang tot gegevens delen, bij elkaar te groeperen en een specifiek Cloud Dataproc/Hadoop-cluster te maken. Op deze manier kunt u gebruikers toevoegen aan de groep die toegang heeft tot de gegevens. Clusterresources kunnen ook worden toegewezen op basis van hun Linux-gebruikers.