Ron_Bennatan_600x448.jpg

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.

Brian_Murphy_600x448.jpg

Waarom uitgebreide ontdekking en analyse uw ongestructureerde datamigratieplan kunnen maken of breken

Klik voor meer informatie over auteur Brian Murphy.

Ongestructureerde data groeien sneller dan ooit. Volgens het huidige onderzoek van de meeste analistenfirma’s groeit het zelfs aanzienlijk sneller dan gestructureerde gegevens. Volgens IDC, 80 procent van wereldwijde data zal tegen 2025 ongestructureerd zijn. En terwijl de enorme hoeveelheid ongestructureerde data zo snel groeit, neemt ook de waarde ervan toe om bedrijven in staat te stellen snellere, slimmere en meer strategische datagestuurde beslissingen te nemen. Bijgevolg overschrijden de capaciteiten in bestandssystemen tegenwoordig doorgaans honderden terabytes (TB’s), en in veel gevallen zelfs meerdere petabytes (PB’s). Dit zijn gegevens die organisaties willen behouden, beschermen en benutten.

Deze enorme groei van ongestructureerde gegevens in bestandssysteemomgevingen heeft het vernieuwen van hardware echter tot een uiterst zwaar proces gemaakt. Wat de uitdaging nog groter maakt, is dat de datasets in deze omgevingen vaak niet volledig worden begrepen als het gaat om gebruiks- en toegangspatronen. In de homedirectory’s van gebruikers in veel bedrijfsomgevingen worden bijvoorbeeld werknemersgegevens opgeslagen die niet essentieel zijn voor het bedrijf. Desalniettemin hebben sommige werknemers hun persoonlijke gegevens intact gelaten door meerdere technische vernieuwingen.

Bovendien kunnen verschillende voorschriften in sommige gevallen resulteren in datasets die voor langere tijd, zo niet voor onbepaalde tijd, moeten worden bewaard en beschermd. Ten slotte is het niet ongebruikelijk dat klanten vast komen te zitten in hun opslagleverancier vanwege de angst voor platformonafhankelijke migraties.

“Een doel zonder plan is slechts een wens.” – Antoine de Saint-Exupery

Planning en voorbereiding zijn ontegensprekelijk de meest kritische stappen in het ongestructureerde data migratie werkwijze. Om het beste plan te implementeren, is het echter van cruciaal belang dat u het beste zicht heeft op uw gegevensomgeving. En de beste manier om dat te doen (zou ik zeggen – de enige manier) is met een softwaretool die diepgaande ontdekkings- en analysemogelijkheden biedt. Wanneer u op zoek bent naar een dergelijke tool, zoek er dan een die direct kan worden aangesloten op de beheer-API van de beste bestandssysteemtechnologieën in de branche om alle relevante paden volledig te ontdekken en te analyseren. Bovendien moet de tool alle volgende gebieden kunnen ontdekken, analyseren en rapporteren:

  • SMB-aandelen
  • NFS-exporten en aliassen
  • Quota (adviserend, zacht en hard)
  • Gebruikte capaciteit
  • Replicatie

Met zo’n planningsrapport in de hand kan de gebruiker de ideale strategie voor de migratie bepalen en deze vervolgens uitvoeren.

Laten we deze kritieke zichtgebieden eens nader bekijken.

SMB / NFS-shares en -exports

Met Shares en Exports moet het ontdekkingsproces van uw softwaretool een rapport kunnen genereren met de volgende gegevenspunten:

  • Bestanden server
  • Pad
  • Gedeelde status
  • Lijst met aandelen, exporten en aliassen
  • Aantal aandelen en exporten
  • Aantal onderliggende aandelen en exporten
  • Aantal moederdelen en exporten

Deze informatie kan op zijn beurt worden gebruikt om te bepalen welke paden relevant zijn in uw omgeving en om een ​​strategie voor uw migratie verder te ontwikkelen. Met deze informatie kunnen beheerders nu bijvoorbeeld meerdere keren identificeren dat exports worden gedeeld en meerdere paden identificeren die nuttig kunnen zijn bij het bepalen van het gebruik van symlinks om dezelfde gebruikerservaring te bieden bij platformonafhankelijke migraties.

Quota

Quotarapporten bieden gebruikers toegang tot informatie die erg handig kan zijn om te bepalen welke waarden mogelijk naar de nieuwe opslag moeten worden gemigreerd. In quotarapporten zou u het volgende moeten vinden:

  • Bestandsserverinformatie
  • Pad
  • Oorsprong van het quotum
  • Capaciteitsquota
  • Capaciteit oorsprong
  • Gebruikte capaciteit
  • Geschatte aantal items

Capaciteit

Capaciteitsrapporten kunnen worden gebruikt om capaciteit in de omgeving op verschillende niveaus te identificeren. Gebruikers kunnen capaciteit afleiden door bijvoorbeeld naar het kindniveau te kijken. Capaciteitsrapporten moeten gebruikers de volgende gegevenspunten bieden:

  • Bestanden server
  • Pad
  • Capaciteit oorsprong
  • Gebruikte capaciteit
  • Geschatte aantal items

Replicatie

Replicatierapporten kunnen worden gebruikt om te bepalen of replicatie op het pad is geconfigureerd, of gegevens worden gerepliceerd als onderdeel van een bovenliggende directoryreplicatie, of onderliggende directory’s worden gerepliceerd, of een gefilterde bestandsset wordt gerepliceerd of dat er helemaal geen replicatie is. De volgende gegevenspunten moeten worden vastgelegd in een replicatierapport:

  • Bestanden server
  • Pad
  • Repliceren
  • Replicatiepaden
  • Replicatiedoelen

Tweemaal meten, eenmaal knippen

De gegevensontdekking en analyse waarvan nu kan worden genoten via geselecteerde softwareoplossingen, zal het creëren en uitvoeren van intelligente datamigratiestrategieën mogelijk maken. Niet alleen dat, maar voor degenen die vervolgens de volgende stap willen zetten, kunnen de bevindingen ook worden gebruikt om te helpen bepalen hoe al die opslag in de nieuwe omgeving kan worden opgedeeld.

Het komt er echter op neer: ik ga erop uit en zeg: absoluut geen enkele beheerder kan het risico lopen dat de gegevensmigratie mislukt. En, zoals Sir Winston Churchill ooit zo welsprekend zei: “Hij die geen plannen maakt, is van plan te mislukken.” Maar met de juiste planning, mogelijk gemaakt door de juiste tools, zal uw volgende ongestructureerde datamigratie een stuk minder stressvol zijn en, nog belangrijker, een groot succes!