Snowflake toegangscontrole op schaal

Steeds meer bedrijven stellen Snowflake centraal in hun data platforms. Zelfs als het een beheerde oplossing is, moet u nog steeds de omgeving beheren. Dat kan een uitdaging zijn, vooral voor grote bedrijven.

Een van de uitdagingen is toegangscontrole. Het is een essentieel onderdeel van elk data governance-programma. Snowflake biedt kant-en-klare functies om deze uitdaging aan te gaan. Maar wanneer u tientallen gebruikers en terabytes aan data hebt, zijn ingebouwde functies niet genoeg. U moet nadenken over een strategie om uw account te beheren.

Wij zijn er geweest. Voor één van onze klanten, We beheerden een account met meer dan 50 actieve gebruikers. We ontwierpen een oplossing om het toegangsbeheer op te schalen.

Dit artikel beschrijft de belangrijkste lessen van het afgelopen jaar.

Voordat we bij het bedrijf kwamen, was de account opgezet en waren er veel goede ideeën geïmplementeerd. Aangepaste rollen was gemaakt. Gebruikers werden zorgvuldig beheerd. Maar er waren een paar beperkingen:

We creëerden een nieuw systeem om de toegangscontrole te beheren en deze tekortkomingen te bestrijden.

Eerst trokken we alle standaard roltoewijzingen (SYSADMIN, USERADMIN ...) aan gebruikers in ... Slechts een paar mensen konden die rollen aannemen. Dat waren de mensen die verantwoordelijk waren voor de administratie.

Ten tweede creëerden we een kader voor toegangscontrole op basis van aangepaste rollen. We hebben twee soorten aangepaste rollen gedefinieerd:

We hebben ervoor gekozen om toegangsrollen te definiëren op het databasisniveau. Het maakt het eenvoudig om de privileges van de ene omgeving naar de andere te repliceren met behulp van zero-copy cloning. Het was ook een afweging tussen de flexibiliteit die we eindgebruikers bieden en de strikte toepassing van het principe van de laagste rechten.

Op het niveau database hebben we 3 niveaus van toegangsrollen gedefinieerd:

We hebben een vergelijkbare strategie toegepast voor toegang tot magazijnen met twee soorten rollen:

Hieronder ziet u een illustratie van ons raamwerk. Pijlen staan voor subsidies.

Op dit punt hadden we een beter idee van hoe we machtigingen zouden beheren, maar we hadden ook problemen met gebruikersbeheer.

We hebben Eenmalige aanmelding zodat Snowflake-gebruikers aanmelden via Azure Active Directory (AAD). Zo hebben we de complexiteit van het onderhouden van twee data-bases van gebruikers weggenomen en was het offboardingproces robuuster. We hoefden de gebruiker alleen maar uit te schakelen in AAD en de verwijdering werd automatisch gerepliceerd naar Snowflake.

Aangezien er een mapping is tussen AD-groepen en rollen in Snowflake, konden we een rol toekennen aan elke gebruiker die we aanmaken. We volgen hetzelfde proces voor elke nieuwe gebruiker.

Dit is het proces voor echte menselijke gebruikers, maar het biedt geen oplossing voor een van de beperkingen die aan het begin van dit artikel werden genoemd: het gebruik van persoonlijke referenties voor geautomatiseerde taken.

Daarom hebben we serviceaccounts. Het beheer van serviceaccounts lijkt erg op wat we zojuist beschreven hebben. Het enige verschil is dat we voor elke serviceaccount een functionele rol maken. Er is een één-op-één relatie tussen servicerekeningen en hun rollen. Daarom beperken we het bereik van de machtigingen voor elke serviceaccount strikt.

Die stappen waren grote verbeteringen. Alles werd gedocumenteerd. Teams namen het nieuwe framework snel over. We waren tevreden.

Maar we besteedden nog steeds veel tijd aan het handmatig verlenen van toegang, en omdat dit erg handmatig was, was het ook foutgevoelig. De behoefte aan een tool om deze taken te automatiseren was duidelijk.

We hadden een paar opties:

Uiteindelijk hebben we een CLI in Python gemaakt.

Wij geven de voorkeur aan het gebruik van Terraform om infrastructuur te implementeren en alleen infrastructuur. Ongewenst gedrag kan optreden wanneer u uw gebruikers en rechten met Terraform gaat beheren. Geheime rotatie is bijvoorbeeld erg moeilijk te beheren.

Wij houden van bash, maar alleen voor ad-hoc en eenvoudige bewerkingen. Hier moeten we configuratiebestanden laden, communiceren met de Snowflake API en data structuren manipuleren. Dit is mogelijk, maar zou op de lange termijn moeilijk te onderhouden zijn.

Naast dit aspect hadden we ook betrouwbaarheid nodig. Eén manier om dit te bereiken is door tests te schrijven. Dit is gemakkelijker te doen in programmeertalen zoals Python.

Wanneer u het hulpprogramma uitvoert, gebeurt er het volgende achter de schermen.

Het is de bedoeling dat de tool geen rol maakt die al bestaat. Hetzelfde geldt voor privileges. De tool berekent de verschil tussen de configuratie en de externe omgeving en past de nodige wijzigingen toe. Hierdoor kunnen we downtime voorkomen.

In eerste instantie hebben we deze tool lokaal uitgevoerd. Maar dit kon tot problemen leiden. We konden bijvoorbeeld conflicten krijgen tussen twee engineers die tegelijkertijd wijzigingen probeerden aan te brengen. Daarom hebben we een workflow gebaseerd op de CI/CD-mogelijkheden van Azure DevOps (ADO).

Opmerking: wij gebruikten ADO, maar u kunt hetzelfde doen met GitHub, GitLab of Bitbucket.

Dit is het uiteindelijke proces.

Deze volledig geautomatiseerde workflow werkt erg goed. Tests vangen defaults vroeg in de CI-pijplijn. En verplichte review is ook een manier om incidenten te voorkomen.

Daarnaast dienen pull requests als een soort documentatie van alle eisen.

Het is nu iets minder dan een jaar geleden dat we deze oplossing in gebruik namen. Hoewel het een initiële tijdsinvestering vergde voor de implementatie, was het het helemaal waard.

We besteden nu meer tijd aan discussies met de gebruikers over hun verzoeken en niet aan de daadwerkelijke implementatie. De meeste verzoeken kunnen worden opgelost in ongeveer 10 regels YAML. Dit is erg efficiënt en het schaalt goed. We verwelkomen nog steeds nieuwe gebruikers en kunnen de vraag aan. Ook hebben we de aanvankelijke problemen opgelost. Het was dus een succes!