Azure en beveiliging

Deze pagina beschrijft de Azure-inrichting die we voor je productieomgeving ontwerpen en opleveren binnen de afgesproken opdracht. Het ontwerp volgt uit de gegevens, gebruikers, processen en beschikbaarheid die jouw organisatie nodig heeft. Een vermelding van Azure is op zichzelf geen bewijs dat een omgeving passend is beveiligd.

Leg daarom vooraf vast wat je wilt beschermen en wie welke verantwoordelijkheid draagt. De demo laat de productwerkwijze zien; de keuzes en controles voor je productieomgeving worden apart uitgewerkt. Je inrichtingsdocument en acceptatieverslag maken later zichtbaar wat is ingericht en getoetst.

We bespreken of de omgeving in je eigen Azure-organisatie wordt geplaatst of in een afzonderlijk ingerichte omgeving die Munitor voor je beheert. Daarbij leggen we vast wie eigenaar is van accounts, configuratie, gegevens en abonnementen, en wie operationele wijzigingen mag uitvoeren.

Bepaal ook waar gegevens, back-ups en relevante loggegevens worden verwerkt. Een gekozen Azure-regio zegt niet automatisch iets over alle gekoppelde diensten of ondersteuning. Breng die gegevensstromen afzonderlijk in kaart.

Voor de maatwerkinrichting werken we met gescheiden ontwikkel-, acceptatie- en productieomgevingen. Nieuwe functies en configuraties worden eerst buiten productie gecontroleerd. Gebruik daarbij bij voorkeur fictieve of geschoonde gegevens; een kopie van productie vraagt om een bewuste afweging en passende bescherming.

We richten persoonlijke beheeraccounts, MFA en beperkte rechten in. Technisch beheer en inhoudelijke dossiergoedkeuring krijgen ieder hun eigen bevoegdheden. Wanneer Entra ID wordt gekoppeld, nemen we ook de afstemming met je identiteitsbeleid mee. Tijdelijke toegang krijgt een eigenaar, doel en eindmoment.

Het ontwerp bepaalt hoe de applicatie verbinding maakt met database, opslag en andere diensten. We beperken onnodige netwerktoegang, beveiligen verbindingen en opslag en leggen vast hoe technische geheimen worden beheerd. Afhankelijk van de gekozen architectuur kunnen bijvoorbeeld beheerde identiteiten, afzonderlijk geheimenbeheer en private verbindingen onderdeel van de inrichting zijn.

Die keuzes moeten aansluiten op de manier waarop je omgeving wordt onderhouden. Een veilige configuratie die bij iedere wijziging handmatig moet worden omzeild, is geen werkbare basis. Documenteer daarom ook het wijzigingsproces, de benodigde bevoegdheden en de controles bij een nieuwe versie.

Spreek af welke gegevens worden geback-upt, hoe lang kopieën bewaard blijven, waar ze staan en wie herstel mag starten. Bepaal daarnaast hoeveel gegevensverlies en onderbreking de organisatie als uitgangspunt accepteert. Die hersteldoelen sturen de inrichting en de benodigde inspanning.

Een geslaagde back-uptaak is nog geen bewijs dat herstel werkt. Bij de afgesproken hersteltest zetten we informatie terug in een geschikte, afgeschermde omgeving en controleren we de bruikbaarheid. Denk aan de samenhang tussen beoordelingen en bewijsbestanden en de toegang na herstel. Leg uitkomsten, afwijkingen en vervolgacties vast.

De acceptatie omvat de overeengekomen toegangscontroles, omgevingsscheiding, logging, hersteltest en beheerafspraken. Leg open punten vast met een verantwoordelijke en een besluit over de ingebruikname. Aanvullend beveiligingsonderzoek kan een afzonderlijk onderdeel van de opdracht zijn.

Na oplevering blijven updates, kwetsbaarheden, toegangsreviews en herstelcontroles aandacht vragen. Spreek supportvensters, opvolging en rapportage concreet af. Certificeringen van Microsoft vervangen die werkzaamheden niet en zijn geen certificering van Munitor of jouw organisatie.