De vijf belangrijkste problemen bij het migreren van database-workloads naar de cloud

Klik voor meer informatie over auteur Ron Bennatan.

Als u verantwoordelijk bent voor het databasebeveiligings- en nalevingsprogramma van uw bedrijf, is de kans groot dat u dit project bent begonnen toen de meeste database-workloads on-premise waren en uw databases in uw eigen datacenters woonden. Hoogstwaarschijnlijk begin je ook aan of zit je al midden in een enorme verschuiving waarbij deze databases naar een openbare cloud verhuizen – meestal Amazon AWS, Microsoft Azure of Google Cloud Platform (GCP).

Enerzijds is een database een database, waar deze zich ook bevindt. Dit geldt meer voor de applicatie-ontwikkelaar en de DBA dan voor de infrastructuurmensen en voor degenen onder ons die verantwoordelijk zijn voor het beveiligen van de database, omdat de beveiligingscontroles en beveiligings- ‘loodgieterswerk’ die altijd deel uitmaken van de clouddiensten een grote rol spelen. verschil. Er is een leercurve, en u moet zich daarvan bewust zijn en deze in uw migratietijdlijn meenemen, zodat u niet overrompeld wordt.

Hier zijn vijf belangrijke dingen waarmee u rekening moet houden bij het beveiligen van uw migratie van databases naar de wolk, maar voordat ik erin spring – een verduidelijking. Er zijn twee manieren waarop u een database in een cloud kunt laten draaien. U kunt een instantie opstaan ​​(bijv. Een EC2-instantie op AWS) en uw database installeren op het Linux- of Windows-besturingssysteem, net zoals u deze installeert op een virtuele machine die op locatie draait (dwz u gebruikt de cloud voor IaaS). Hoewel er enkele services zijn waarvan u kunt profiteren (u kunt bijvoorbeeld een AWS-agent gebruiken om uw databaselogboeken naar Cloudwatch door te sturen), is dit voor mij niet echt een database in de cloud.

Het is niet anders dan op locatie – u draait het gewoon in een ander datacenter. De tweede optie is om de database als een service te krijgen, bijvoorbeeld RDS of RedShift als een AWS-service of SQL Azure, GCP BigQuery of Snowflake. U ‘huurt’ capaciteit voor een database als een service en krijgt veel meer services rechtstreeks uit de cloud. Dit DBaaS-patroon is waar ik aan denk als ik denk aan het migreren van database-workloads naar de cloud, en de lijst met vijf verwijst naar DBaaS.

1. Public Cloud is zowel veiliger als minder veilig dan op locatie
Huh?!? Wat betekent dat uberhaupt? Laat het me uitleggen. Openbare clouds zijn de afgelopen tien jaar vanaf de grond opgebouwd en er zijn veel redenen waarom ze eigenlijk veiliger zijn dan 90 procent van alle zakelijke datacenters. De technologie die ze gebruiken is bijna altijd nieuwer en recenter dan wat de meeste bedrijven zich kunnen veroorloven, en de niveaus van standaardisatie en consistentie zijn ordes van grootte hoger.

Er is geen “maatwerk” in cloudomgevingen – alles is hetzelfde, en daarom zijn er minder kansen op ongelukken als gevolg van eenmalige acties. De mensen die ze hebben gebouwd, hebben meestal diepere technische expertise en een robuustere beveiligingsmentaliteit. Cloudproviders begrijpen ook dat elk beveiligingsincident zulke grote schade aan hun bedrijf toebrengt dat de inzet niet hoger kan zijn. Cloudleveranciers bieden veerkrachtniveaus waar de meeste bedrijven niet eens van kunnen dromen. Andere voorbeelden zijn patching en kwetsbaarheden. De cloud biedt patch-systemen voor u – ze vragen u hier niet eens naar, en u kunt ze ook niet vragen niet om het te doen. Dat is de manier waarop het zou moeten zijn.

Hetzelfde geldt ook voor DBaaS-omgevingen. Dingen zijn consistent, standaard en ingebouwd – dus veiliger. Patches worden voor u aangebracht. Versies zijn recent (ik heb onlangs gewerkt met een klant die nog steeds Oracle 7 draait! Je zult dat soort dingen niet vinden op openbare clouds!). Dus waarom zeg ik dat het ‘zowel veiliger als minder veilig is?’ Vanuit technologisch oogpunt is de cloud veel veiliger. Waar het “minder” binnenkomt, is de “menselijke factor”. Veel bedrijven bevinden zich in de overgangsmodus en verplaatsen workloads naar de cloud. Heel vaak, de verantwoordelijken want de database en de applicatielagen zijn geen experts in cloudservices, en dit is waar je op moet letten. Er kunnen fouten worden gemaakt en mensen zijn altijd de zwakste schakel als het gaat om informatiebeveiliging, dus hoe meer u zich houdt aan sjablonen, best practices of tools met beveiligingscontroles voor DBaaS, hoe kleiner de kans op menselijke fouten.

2. Databasebeveiliging moet worden “ingebakken” in uw database-bezorgingsstapel en volledig geautomatiseerd zijn
Cloud-omgevingen en DBaaS zijn specifiek dynamische omgevingen en van nature kortstondig. Applicatieteams zijn dol op clouds omdat ze direct nieuwe databases kunnen opstarten. Maar dat betekent dat elk beveiligingsinitiatief dat afhankelijk is van vaste lijsten met hosts, IP’s, gebruikers of tupels attributen, gedoemd is te mislukken – en vrijwel alle implementaties van databasebeveiliging die zijn uitgevoerd voor on-prem systemen zien er zo uit.

In de cloud moeten dingen worden ‘ontdekt’ en niet ‘gedefinieerd’. Probeer geen lijsten te beheren – probeer een proces te beheren waarbij, wanneer een database verschijnt, uw beveiligingsoplossing deze automatisch vindt en uw beveiligingsmaatregelen er automatisch op toepast. En trouwens – als je eenmaal begrijpt dat dit mogelijk is in de cloud, moet je ook begrijpen dat het ook on-prem kan – en dat het toepassen van deze automatiseringsprincipes ook op on-prem-omgevingen je niet alleen veiliger zal maken. maar zal vanuit het oogpunt van onderhoud een enorme last van u afnemen. Genoeg met de lijstjes!

3. Te veel variatie in DBaaS
Ook al zorgt de cloud voor standaardisatie, er is nog steeds veel (misschien te veel?) Variatie in hoe DBaaS eruitziet en wat er nodig is om het te beveiligen. Allereerst brengt de cloud een explosie van databasetypen met zich mee. Waar tien jaar geleden de meeste bedrijven 3-4 databasetypen hadden, is het nu in de tientallen en groeit het. Het heeft niet allemaal te maken met de cloud – het is vaak toeval met de cloud. NoSQL, big data en gespecialiseerde databases worden nu door iedereen gebruikt en DB Engines houden het gebruik bij van meer dan 350 databasetypen. Maar het is niet alleen de timing (bijvoorbeeld dat NoSQL en Cloud-acceptatie deel uitmaken van hetzelfde decennium). Veel databases worden alleen aangeboden als een DBaaS-service op clouds – voorbeelden zijn onder meer AWS Redshift, GCP BigQuery, Snowflake, AWS DocumentDB, AWS DyamoDB en Azure CosmosDB.

Maar zien al deze diensten er hetzelfde uit? Nee. Sommige bestaan ​​alleen in de cloud en zijn dus zeer nauw geïntegreerd in de cloudstructuur. Maar sommige zijn echt ‘een database’ die wordt aangeboden als een cloudservice, maar ‘binnen ziet er normaal uit’. Voorbeelden zijn RDS Oracle, SQL Server, MySQL en PostgreSQL. Oracle op RDS is bijvoorbeeld gewoon een Oracle dat Amazon heeft geïnstrumenteerd zodat het kan worden gecontroleerd en beheerd met behulp van de cloud-fabric. Dit betekent dat elk databasetype dat in de cloud wordt uitgevoerd, varianten heeft in termen van hoe u beveiligingsmaatregelen toepast, en dit maakt het moeilijker voor u – onthoud punt 1. Standaardisatie is goed. Het is belangrijk om de beveiligingscontroles consistent te krijgen, ongeacht het databasetype, om nog maar te zwijgen over het feit of je consistentie nodig hebt over meerdere clouds of zelfs over meerdere clouds en op locatie!

4. Overweeg de loodgieterskwesties
Als uniformiteit je vriend is en variatie je vijand, denk dan ook aan de ‘leidingen’ die je moet managen als je zaken doet als monitoring en auditing. In sommige clouds zijn de zaken vrij uniform: in Azure stroomt bijvoorbeeld bijna alles via Event Hubs en in GCP bijna altijd via een combinatie van StackDriver en PubSub. Maar in AWS is het een beetje rommeliger. Sommige dingen gaan via CloudWatch-logboeken, andere via CloudTrail en andere via Database Activity Streams (DAS). Sommige produceren bestanden in S3, en andere leven gewoon in de database. U moet zich bewust zijn van deze leidingen of een tool gebruiken die deze leidingen voor u beheert voor databasebeveiliging, omdat u geen agents of proxy’s kunt gebruiken voor cloudtoegang (ze werken gewoon helemaal niet voor clouds). Soms heb je zelfs meerdere opties om iets te doen – je kunt bijvoorbeeld kiezen welk ‘sanitair’ je wilt gebruiken – maar je moet de voor- en nadelen van elke optie begrijpen.

5. Cloud is niet goedkoper als u niet oplet
En tot slot kunnen al deze beslissingen zelfs uw kosten beïnvloeden. Je betaalt voor alles in de cloud (en het is erg duur als je alles optelt). U moet alle dingen begrijpen waarvoor u moet betalen en welke opties u heeft, en soms zijn de kosten van invloed op uw beslissing. In sommige van de RDS-varianten kunt u bijvoorbeeld een auditaanpak kiezen die CloudWatch-logboeken gebruikt en een auditaanpak die dat niet doet. Aan de behoeften op het gebied van beveiliging / compliance wordt op bijna identieke wijze voldaan, maar de kosten zijn verschillend. U betaalt ongeveer $ 0,50 per GB verzameld in een CloudWatch-logboek. Als uw database 2 GB per dag produceert en u 1000 RDS-instances heeft, betaalt u ongeveer $ 360K per jaar alleen voor het doorvoeren van de logboeken door deze pipe naar uw databasebeveiligingstool. Maar als deze tool weet hoe het rechtstreeks uit de database moet worden gehaald, of als u S3 doorloopt, kunt u deze kosten besparen.

Er zijn natuurlijk veel andere belangrijke dingen die u moet weten en overwegen bij het implementeren van databasebeveiliging voor DBaaS. Maar voor mij zijn de sleutels uniformiteit en standaardisatie. Op dezelfde manier dat ik denk dat de cloud veiliger is dan niet-cloud in het algemeen, denk ik dat een implementatie die gebruikmaakt van één set besturingselementen voor alle databases – of het nu op één cloud, op veel clouds en / of op locatie is – maakt de overgang naar de cloud niet alleen eenvoudiger en sneller, maar verhoogt ook de beveiliging aanzienlijk.

follow:
admin

admin

Related Posts

Een korte geschiedenis van gegevensbeheer

Datamanagement is de organisatie van gegevens, de stappen die worden gebruikt om efficiëntie te bereiken en informatie uit die gegevens

Datakans klopt! Moet je antwoorden?

Klik voor meer informatie over auteur Kartik Patel. Als zakenmensen krijgen we vaak te maken met wat misschien een geweldige

Een korte geschiedenis van gegevensbeheer

Datamanagement is de organisatie van gegevens, de stappen die worden gebruikt om efficiëntie te bereiken en informatie uit die gegevens

Datakans klopt! Moet je antwoorden?

Klik voor meer informatie over auteur Kartik Patel. Als zakenmensen krijgen we vaak te maken met wat misschien een geweldige