Afwegingen voor beveiliging

Beveiliging biedt vertrouwelijkheid, integriteit en beschikbaarheidsgaranties van de gegevens en systemen van een organisatie. Bij het ontwerpen van een systeem kunt u bijna nooit in gevaar komen met beveiligingscontroles. Wanneer u de beveiliging van een architectuur verbetert, kan dit van invloed zijn op de betrouwbaarheid, efficiëntie van prestaties, kosten en operationele uitmuntendheid. In dit artikel worden enkele van deze overwegingen beschreven.

Beveiliging versus betrouwbaarheid

Betrouwbare toepassingen zijn robuust en zeer beschikbaar. Elk architectuuronderdeel moet rekening houden met het bereiken van uw vereisten voor betrouwbaarheid. Workloadbeveiliging wordt vaak in veel lagen van de architectuur, bewerkingen en runtimevereisten van de workload op elkaar geseed; en kunnen hun eigen gevolgen hebben voor tolerantie of beschikbaarheid.

Id-providers en autorisatieservices zijn bijvoorbeeld essentiële afhankelijkheden om rekening mee te houden. Dit omvat de identiteitsservice (Microsoft Identity Platform) en bibliotheken die het gebruik van deze services mogelijk maken. Op sommige punten in de architectuur is een fout in een identiteitslaag terminal. Op andere punten kan betrouwbaarheid nog steeds worden bereikt via strategieën zoals caching, profiteren van TTL's voor toegangstokens en andere. Validatie van OAuth2-claims kan voornamelijk plaatsvinden als de verbinding met de claimprovider is verbroken. Niet alle autorisatie kan echter op die manier worden bereikt. In dergelijke situaties kan de betrouwbaarheid worden inruilen voor volledige beveiliging.

Veel workloads kunnen snel verslechteren in functionaliteit met het verlies van kritieke beveiligingscontroles. Overweeg de evaluatie van elk onderdeel van uw architectuur om die voorwaarde te detecteren.

Andere beveiligingsoverwegingen die van invloed kunnen zijn op de betrouwbaarheid zijn:

• Slechte of handmatige certificeringen of procedures voor sleutelrotatie. Als deze taken niet worden uitgevoerd, kan dit leiden tot problemen met de betrouwbaarheid.
• Verlopen service-principals. Een implementatiepijplijn die gebruik maakte van een service-principal kan bijvoorbeeld op een later tijdstip mislukken als de toegangssleutel van die principal is verlopen. Het gebruik van beheerde identiteiten zorgt ervoor dat de betrouwbaarheid hoog blijft en tegelijkertijd de minste bevoegdheden voor die identiteit behouden blijven.
• Hoge beschikbaarheid wordt vaak bereikt door redundantie (actief of passief) en beveiligingsmaatregelen moeten ook worden uitgelijnd met het failovermechanisme. Een voorbeeld: een failing over te brengen van het ene opslagaccount naar het andere kan van invloed zijn op de manier waarop de actieve autorisatiesessie van de client wordt verwerkt. Het gebruik van beheerde identiteit met Azure AD-integratie voor opslagtoegang kan leiden tot een hogere betrouwbaarheid, omdat de client geen SAS-tokens hoeft te beheren bij het overschakelen naar het nieuwe opslagaccount.

Beveiliging versus kostenoptimalisatie

Het verhogen van de beveiliging van de workload leidt bijna altijd tot hogere kosten. Er zijn enkele manieren om de kosten te optimaliseren.

• Maximale beveiliging is mogelijk niet altijd praktisch voor alle omgevingen. Evalueer de beveiligingsvereisten in preproductie- en productieomgevingen. Zijn services zoals Azure DDoS Protection, Azure Sentinel, toegewezen HMS'Azure Defender nodig in de preproductie? Is inner loop mocking van beveiligingscontroles voldoende? Als resources niet openbaar toegankelijk zijn, kunt u dan enkele besturingselementen inbelen voor kostenbesparingen? Maak altijd deze keuzes, als en alleen als, de verlaagde omgeving nog steeds voldoet aan de bedrijfsvereisten.

• Premium beveiligingsfuncties kunnen de kosten verhogen. Er zijn gebieden waar u kosten kunt verlagen met behulp van native beveiligingsfuncties. Vermijd bijvoorbeeld het implementeren van aangepaste rollen als u ingebouwde rollen kunt gebruiken.

• Elk beveiligingsbeheer heeft de mogelijkheid om invloed te hebben op werkstromen en werkstromen waarbij mensen betrokken zijn, kunnen duur zijn. Een besturingselement voor beveiliging dat het werk stopt, moet worden geëvalueerd als noodzakelijk of onnodig redundant. De totale eigendomskosten (TCO) omvatten operationele kosten voor ontwikkelaars, operators, IT SecOps en onereuze beveiligingsprotocollen. Overeenstemming bereiken over waar 'minder' voldoende kan zijn om de kosten te optimaliseren.

• TCO bevat de tijd die nodig is om taken uit te voeren. Als u die tijd optimaliseert, worden de kosten geoptimaliseerd. Het gebruik van platformfuncties kan de TCO verlagen en de beveiligingsstatus verbeteren. In plaats van een technicus te trainen om logboeken handmatig te controleren en toegangspatronen te correleren, gebruikt u intelligentie in services, Azure Defender of Sentinel-waarschuwingen.

Beveiliging versus operationele uitmuntendheid

Operationele uitmuntendheid omvat inzicht in het gedrag van bedrijven en workloads en het toepassen van de juiste hoeveelheden automatisering en waarneembaarheid in deze processen.

• Releasebeheer

  Uw organisatie definieert de kwaliteitspoorten (handmatig of geautomatiseerd) als onderdeel van de veilige implementatieprocedures. Evalueer of elke poort vereist of optioneel is, waarbij u rekening houdt met het feit of deze waardevol is om uit te voeren, tegen de extra kosten van complexiteit (en tijd) voor die release. Door beveiligingscontroles toe te voegen aan het proces, zijn de controles op dat punt in het proces waardevoller dan eventuele voordelen (meestal eenvoud en tijd) door ze niet te gebruiken.

• Organisatiebeleid

  Teams kunnen vaak profiteren van samenwerking en het gebruik van cross-functionele vaardigheden in alle fasen van de levenscyclus van workloads, van ontwikkeling tot aan de productie. Organisatiebeleid of regelgeving kan dergelijke brede toegang echter verhinderen. Overweeg waar mogelijk de systemen te isoleren die wel een verhoogd toegangsbeleid nodig hebben dan systemen die dat niet doen. Vermijd het toepassen van het model 'one size fits all' op alle onderdelen in het systeem. Het is eenvoudiger om bewerkingen te optimaliseren in systemen die niet-gereglementeerde toegang toestaan. Voor systemen die gereguleerde toegang nodig hebben, zal de complexiteit naar verwachting toenemen, wat leidt tot hogere kosten.

• Overwegingen voor ondersteuning

  De meest 'serviceeerbare' architecturen zijn de architecturen die het meest transparant zijn voor alle betrokkenen en die vaak het minste aantal beveiligingscontroles hebben. Het toevoegen van besturingselementen voor beveiliging aan uw architectuur, zoals gefilterde telemetriefeeds, redacted logboeken, toegangsbeperkingen voor runtime-systemen, kan allemaal van invloed zijn op de ondersteuning van een oplossing. Het toevoegen van beveiligingscontroles vereist vaak het toevoegen van compenserende of aangetaste oplossingen voor waarneembaarheid aan het platform.

Gerelateerde koppeling

Terug het hoofdartikel: Beveiliging