FOD Financiën Programma Multi-kanaal Dienstverlening Security & Control V3.0

FOD Financiën Programma Multi-kanaal Dienstverlening Security & Control V3.0

Voorgelegd ter validatie aan het ICT-team, het kernteam en de stuurgroep van 16/06/2004 Voorstudie Programma MKDV.

Inhoudstabel Blz. 1. Samenvatting....................................................................................................................... 3 2. 3.

Structuur en aanpak............................................................................................................. 5 Functionele beveiliging : Vereisten en Oplossingen ........................................................... 7 3.1.

3.2.

3.3.

3.4.

4.

7 7

3.1.2. MKDV Gebruikers Autorisatie van toegang tot functionaliteiten van het MKDV systeem

11 12

3.2.1. 3.2.2.

12 13

Vraagstellers MKDV Gebruikers

Autorisatie van toegang tot de externe gegevens van het MKDV programma 3.3.1. Vereisten

15 15

3.3.2. Oplossingen Traceerbaarheid

15 16

3.4.1. 3.4.2.

16 16

Vereisten Oplossingen

Technische beveiliging : Vereisten en Oplossingen.......................................................... 18 4.1. Beveiliging van de infrastructuur 18

4.2.

5. 6.

Identificatie en authentificatie 3.1.1. Vraagstellers

4.1.1. 4.1.2.

Databanken Platformen

18 18

4.1.3. 4.1.4.

Netwerk Fysieke omgeving

19 21

Beveiligingsbeheer 4.2.1. Operationeel beheer

23 23

4.2.2. 4.2.3.

25 26

Ontwikkeling Oplossingen

Samenvatting van de oplossingen ..................................................................................... 27 Bijlagen ............................................................................................................................. 29 6.1. 6.2.

Vertrouwelijk

Lijst van use cases Verklarende woordenlijst

29 30

© FOD Financiën

Security & Control V3.0 2 Gevalideerd door stuurgroep van 16/06/2004

Dit document beschrijft de noden en oplossingen inzake beveiliging van de functionele en technische systeemarchitectuur, ontwikkeld in het kader van de voorstudie van het MKDV project. Het is de bedoeling om dit document te gebruiken als referentie bij de implementatie van het toekomstige systeem door zich ervan te vergewissen dat adequate beveiligingscontroles worden ontwikkeld en geïmplementeerd teneinde een aanvaardbaar beveiligingsniveau te bereiken in het MKDV project. Functionele beveiliging In een eerste fase hebben wij een analyse uitgevoerd van de beveiliging verbonden aan de functionaliteit van het MKDV systeem. De vereisten en te de implementeren oplossingen zijn gedefinieerd volgens de volgende criteria : • • •

Identificatie en authentificatie van de vraagstellers (particulieren, bedrijven, mandatarissen, enz .) en gebruikers Autorisatie van de toegang tot de gegevens en de functionaliteit van het systeem Traceerbaarheid van de transacties binnen de applicatie

Bij alle toepasbare oplossingen voor de verschillende beveiligingsaspecten is het sterk aangeraden dat die goed zijn geïntegreerd in andere bestaande (CCFF) en/of toekomstige systemen, zowel intern (Identity Management) als extern (FedICT). Een geïsoleerde implementatie zou immers ingaan tegen de strategie van standaardisatie van de systemen binnen de FOD Financiën en een belangrijke meerkost betekenen voor de realisatie van een afdoend beveiligings- en controleniveau De implementatie van deze oplossingen in de praktijk is afhankelijk van de vooruitgang van de projecten die tijdens de verschillende MKDV implementatiefases moeten worden geïntegreerd. Technische beveiliging Om de nodige functionaliteiten aan de vraagstellers en gebruikers te kunnen aanbieden, moet de MKDV applicatie worden ondersteund door een technische infrastructuur en een operationeel beheersysteem. Analoog aan de functionele aspecten moet ook de technische infrastructuur van het MKDV systeem zich integreren in de bestaande en toekomstige standaarden en projecten binnen de FOD Financiën zoals de netwerkarchitectuur, CCFF en de Atlas infrastructuur. Op vlak van beveiliging moet dit alles in overeenstemming gebeuren met de beveiligingsvereisten voor de databases, de besturingssystemen de netwerken en de fysieke omgeving zoals gedefinieerd in dit document. De beveiligingsvereisten omvatten de volgende elementen: • • • •

Een scheiding in infrastructuurniveaus Toegangscontrole voor de verschillende systemen en componenten Een veilige configuratie van de verschillende componenten (databank, besturingssysteem, fire walls, enz.) bewaken van de beveiligingsincidenten (toezicht en opvolgen)

Bij het operationeel beheer en de ontwikkeling van de MKDV toepassing moet ook rekening worden gehouden met het aspect beveiliging van de informatie. Om een systeem zoals MKDV op een veilige manier te ontwikkelen en te beheren moeten immers een beveiligingspolitiek en beveiligingsprocedures worden geïmplementeerd om een maximale controle te kunnen uitoefenen op zowel de functionele als de technische aspecten van het systeem. Dit document geeft een beschrijving van de belangrijkste aspecten die moeten worden opgenomen in een dergelijk veiligheidsbeheer. Zoals hierboven reeds vermeld is het niet aangewezen om een volledig beveiligingsbeheersysteem uitsluitend voor MKDV op te zetten. Dit beheer moet een onderdeel uitmaken van een ruimere visie met betrekking tot informatiebeveiliging binnen de FOD Financiën. Deze integratie laat een betere standaardisatie van procedures en Vertrouwelijk

© FOD Financiën


systemen toe, wat een verhoogd niveau van beveiliging en controle met zich meebrengt alsook lagere kosten voor het MKDV project zowel op vlak van de implementatie als van het operationeel beheer.

Vertrouwelijk

© FOD Financiën


Om de verschillende types van beveiligingsvereisten, die werden geïdentificeerd in het kader van deze studie, te structureren hebben wij gebruik gemaakt van het volgende model :

Beveiligingsmodel

•

De MKDV applicatie vormt de kern van het systeem. Alle functionaliteiten zitten in deze laag alsook de respectievelijke operationele processen.

•

Deze processen worden ondersteund door een informatica infrastructuur bestaande uit databanken, besturingssystemen, netwerkaansluitingen een fysieke infrastructuur.

•

De MKDV toepassing en zijn infrastructuur moet worden ontwikkeld en beheerd in overeenstemming met de operationele en functionele vereisten beschreven in het ICT beheer.

De eerste groep beveiligingsvereisten betreft de functionaliteiten van de MKDV applicatie. Die worden in het eerste hoofdstuk beschreven en omvatten de volgende veiligheidsprincipes: •

Authentificatie : Hoe kan het systeem er zeker van zijn dat de gebruiker/vraagsteller wel degelijk diegene is die hij beweert te zijn?

•

Autorisatie: Hoe kan het systeem onderscheiden of gebruikers/vraagstellers toegang hebben tot bepaalde functionaliteiten en bepaalde informatie?

•

Traceerbaarheid: Hoe kan het systeem de acties van de gebruikers/vraagstellers registreren om een adequate traceerbaarheid op lange termijn te garanderen?

Vertrouwelijk

© FOD Financiën


De tweede groep van beveiligingsvereisten omvat de technische aspecten van het MKDV systeem. Hierbij wordt er een onderscheid gemaakt tussen de informatica infrastructuur en het beheer van de beveiliging van deze infrastructuur. Deze twee delen worden beschreven in het tweede hoofdstuk van dit document en omvatten de volgende veiligheidsprincipes: •

vertrouwelijkheid : Hoe kan het systeem verzekeren dat vertrouwelijke informatie niet toegankelijk is voor niet-geautoriseerde gebruikers?

•

Integriteit : Hoe kan het systeem ervoor zorgen dat de opgeslagen en behandelde informatie intact en veilig blijft?

•

Beschikbaarheid: Hoe verzekert het systeem zich ervan dat het de informatie verstrekt aan de gebruikers en dat wanneer dat nodig blijkt?

Wij merken op dat wij het belang van het principe van « beschikbaarheid » erkennen binnen de context van de informatiebeveiliging: de aspecten continuïteit en contingentering zijn beschreven in het huidige document. Gelet evenwel op de integratievereisten tussen MKDV en de CCFF/Atlasinfrastructuur zijn de andere aspecten inzake beschikbaarheid begrepen in de capaciteitsplanning opgenomen in het document dat de technische architectuur beschrijft. Dit document baseert zich op de beschikbare documentatie zoals het ICT Coperfin boek, de visie en specifieke informatie met betrekking tot de verschillende andere lopende projecten (Identity Management, CCFF, Atlas, informaticastandaarden, enz.) alsook op gesprekken met verscheidene informaticiverantwoordelijk voor de genoemde projecten. . Om de globale federale informaticavisie en het gecentraliseerde beheer van de identiteit van burgers en bedrijven te begrijpen vonden er tevens vergaderingen met het personeel van FedICT plaats.

Vertrouwelijk

© FOD Financiën


De analyse van de beveiliging van de functionele architectuur is opgedeeld in 4 delen: identificatie en authentificatie, autorisatie op functionaliteiten, autorisatie op externe data en traceerbaarheid. Voor elk van deze 4 delen werden de beveiligingsvereisten en mogelijke oplossingen voor het systeem gedefinieerd op basis van de volgende drie voorziene implementatiescenario’s: Scenario 1 : deze eerste implementatiemogelijkheid houdt geen rekening met eventuele andere systemen en vereist dat alle noodzakelijke functionaliteiten worden ingebouwd in het MKDV systeem zelf. Het is een “stand alone” implementatie. Dit scenario sluit ook alle integratie uit met andere bestaande of toekomstige systemen. Het is op te merken dat de algemene aanpak van het MKDV project een integratie met de standaarden van de FOD Financiën en andere lopende projecten voorziet. Derhalve is scenario 1 nooit beschouwd als een reële implementatiemogelijkheid, omwille van onder meer de specifieke middelen die vereist zijn om een dergelijk scenario te implementeren. Scenario 2 : de tweede implementatiemogelijkheid houdt rekening met de bestaande « As Is » omgeving van de FOD Financiën en de andere potentiële organisaties verbonden met dit project. Dit scenario wordt beschouwd als een tussenoplossing in afwachting van de mogelijkheid en noodzaak tot integratie met andere systemen die in sommige gevallen nog in een projectstadium zijn. Scenario 3 : de laatste implementatiemogelijkheid die in deze analyse in aanmerking wordt genomen is de toekomstige « To Be » omgeving van de FOD Financiën en de andere verbonden organisaties. Dit scenario baseert zich op de verschillende lopende projecten en de informaticastrategie van de FOD Financiën. Het wordt beschouwd als een langetermijnoplossing die een optimaal niveau aan beveiliging toelaat, dankzij een integratie met de toekomstige interne en/of externe systemen. In het kader van deze analyse werden enkel de « use cases »1 in detail geanalyseerd die een direct verband hadden met de beveiliging van informatie. Het gaat om de volgende use cases: • De use cases i in verband met de identificatie en authentificatie van de vraagsteller: I1, I2, I3, I7, I8, I6, I15, I16, I17, I18 • De use cases verbonden aan het beheer van de gebruikers in het MKDV systeem: O1 tot O14.

!"

De vereisten op het vlak van identificatie en authentificatie voor de vraagstellers (particulieren, bedrijven, mandatarissen, enz.) hangen in de eerste plaats af van de volgende vraag : « tot welke functionaliteiten en gegevens moeten de vraagstellers toegang hebben ? ». Dit varieert in functie van het kritieke karakter en van de confidentialiteit van de informatie die kan worden opgevraagd of gewijzigd. Bijgevolg is het mogelijk dat een vraagsteller anoniem blijft, zich identificeert, zich authentificeert of een sterk authentificatie middel gebruikt.

1Een gedetailleerde lijst van de hierna vermelde use cases kan u in bijlagen terugvinden.

Vertrouwelijk

© FOD Financiën


Om de noden op het vlak van authentificatie te kunnen definiëren moet er een classificatie van de gegevens (en mogelijk ook van de functionaliteiten) gemaakt worden in overeenstemming met een beveiligingspolitiek (zie 4.2 Beveiligingsbeheer). Verschillende niveau’s van identificatie en authentificatie werden gedefinieerd voor de verschillende toegangsmogelijkheden tot het MKDV systeem: •

Anoniem : de vraagsteller levert geen enkele informatie met betrekking tot zijn identiteit.

•

Identificatie : de vraagsteller geeft een identificatie, maar er is geen verificatie van deze informatie.

•

Authentificatie : de vraagsteller levert bijkomende informatie die toelaat om zijn identiteit te valideren met een zekere graad van vertrouwen.

•

Sterke authentificatie : de vraagsteller levert voldoende informatie om zijn identiteit unaniem en legaal te bewijzen.

Om de toegang tot de mogelijke functionaliteiten en gegevens te bepalen werden er voor ieder kanaal identificatie en authentificatie methoden gedefinieerd alsook hun respectievelijk niveau van vertrouwen. De indeling van de informatie volgens kritieke eigenschappen en nood op het niveau van authentificatie was niet beschikbaar op het moment van de uitvoering van deze studie, maar die zal moeten worden geïmplementeerd door de verschillende processen of pijlers in overeenstemming met de juridische diensten en met de data classificatie politiek. .

De toekomstige oplossingen moeten per kanaal worden onderscheiden : in bepaalde gevallen hebben de vraagstellers geen directe toegang tot het systeem en zal een operator dit voor hun doen; in andere gevallen beschikken de vraagstellers over directe toegang tot het MKDV systeem. Niettemin moeten er voor alle gevallen identificatie en authentificatie oplossingen worden goedgekeurd. .

# $% &&#%" ''

$

#

( $ $ ( " %)% *

Voor de volgende kanalen gebruiken de vraagstellers een communicatiemiddel om in contact te treden met de FOD Financiën, die vervolgens toegang zal hebben tot het MKDV systeem om op de vraag te kunnen antwoorden en om de gevraagde informatie te kunnen aanleveren. Persoonlijk Onthaal De identificatie en authentificatie van personen gebeurt op een manuele manier op basis van de identiteitskaart, dossiernummers en eventuele andere inlichtingen. In de toekomst kunnen ook lezers voor de digitale identiteitskaart worden gebruikt. Contact Center - Telefoon De identificatie per telefoon is gemakkelijk, maar de authentificatie vereist meer geavanceerde technische middelen. Automatische authentificatie oplossingen via telefoon zijn beschikbaar op de markt. Desondanks werd er op het tijdstip van deze studie nog geen oplossing vooropgesteld door de gesprekspartners van de FOD Financiën. Het maken van deze keuze vormt geen onderdeel van h deze voorstudie. Vertrouwelijk

© FOD Financiën


Contact Center - Correspondentie De identificatie voor correspondentie gebeurt op basis van de naam van de bestemmeling, een dossiernummer of andere in de correspondentie beschikbare informatie. De authentificatie van personen zal gebaseerd zijn op de technische oplossingen die door de andere projecten en systemen zullen worden aangeboden (scanning van correspondentie, OCR, enz.) maar kan ook eventueel manueel gebeuren op basis van de handtekening van de vraagsteller, die een wettelijk erkend bewijs vormt van de identiteit van een persoon. De verschillende identificatie en authentificatie mechanismen voor deze kanalen (procedures en technische middelen) zijn in deze voorstudie niet in detail bestudeerd. Er is dus nog geen enkel specifiek scenario aan te bevelen voor de hierboven vermelde communicatiemiddelen.

# $% &&#%

(+ # #

( $ $ ( " %)% * ' % " ,,

Voor het Internet kanaal zal de vraagsteller zich direct op het MKDV systeem moeten identificeren en mogelijk ook authentificeren: Internet – Gestructureerde E-mail Het gebruik van het gestructureerde e-mail kanaal zal worden gerealiseerd via een formulier dat beschikbaar zal worden gemaakt op de « self-service » site. Daarom zal, indien er een authentificatie gewenst is, die gebaseerd zijn op de authentificatie van het « self-service » kanaal. De identificatie zal plaatsvinden via de naam of het e-mail adres van verzender van de e-mail. Self-service De identificatie van de vraagsteller kan eenvoudig worden gerealiseerd op basis van de naam, het e-mail adres of andere informatie die door de vraagsteller op de “self service” site werd ingevoerd De specifieke implementatie (scenario 1) van een authentificatie systeem (zwak of sterk) in het MKDV systeem met al zijn mogelijke vraagstellers is omwille van praktische redenen niet aan te bevelen. Dit vereist middelen die binnen het project niet beschikbaar zijn. Dus moet het systeem zich baseren op de externe federale systemen. In deze context stelt FedICT authentificatiediensten voor met betrekking tot zowel burgers als bedrijven: Ten eerste laat een « user management » systeem toe dat burgers zich identificeren volgens 3 vertrouwensniveau’s : •

Een gebruikersaccount (User ID) en een wachtwoord : op basis van het identiteitskaartnummer, het SIS kaartnummer en het rijksregisternummer kan een burger informatie krijgen om hem/haar te authentificeren (user ID en wachtwoord).

•

Een gebruikersaccount (User ID), een wachtwoord en een token met een lijst van 24 wachtwoorden waarvan er één wordt gevraagd op het moment van de authentificatie. Het verkrijgen van een dergelijk token moet volgens een goed gedefinieerde controleprocedure gebeuren.

•

Elektronische identiteitskaart en een PIN code: verificatie van de geldigheid van het certificaat op de identiteitskaart. De uitrol van de elektronische identiteitskaart is in uitvoering : enkele pilootgemeenten vervangen nu de klassieke identiteitskaart van hun inwoners; de andere gemeenten zullen dit op een progressieve manier uitvoeren. Niettemin zal de volledige uitrol van de elektronische identiteitskaart nog wel enkele jaren in beslag nemen.

Vertrouwelijk

© FOD Financiën


Ten tweede kunnen bedrijven via het doorlopen van een strikte controle en registratieprocedure toegang creëren voor hun werknemers en aangeduide mandatarissen. Deze kunnen zich authentificeren via 2 manieren: •

Een gebruikersaccount (User ID) en een wachtwoord

•

Het gebruik van een certificaat van niveau 3 (die een strikte toekenningsprocedure vereist, inclusief persoonlijk aanbieden).

Het beheer van de vraagstellers (particulieren, bedrijven, mandatarissen en anderen) en de hiermee verbonden controles zijn gecentraliseerd en geregeld door bestaande procedures die werden ontwikkeld door FedICT. Bovendien is er een « helpdesk » beschikbaar om burgers en bedrijven te helpen bij eventuele problemen. Voor deze twee types van oplossingen biedt FedICT bij nieuwe applicaties diensten aan voor de integratie in hun authenticatiesystemen. Deze diensten, in de vorm van een plug-in gebaseerd op de SAML standaard, vragen weinig middelen om te implementeren. Tevens is de nodige documentatie (cook book) voor de integratie van dergelijke diensten beschikbaar. De volgende tabel geeft een overzicht van de door FedICT voorgestelde oplossingen en van de types van authentificatie nodig voor het MKDV project.

Authentificatieniveau FedICT Niveau 1 Niveau 2 Niveau 3

Authentificatie van burgers User ID + wachtwoord User ID + wachtwoord + token Elektronische identiteitskaart + PIN

Authentificatie van bedrijven User ID + wachtwoord N/A Certificaten

Type Authentificatie MKDV Authentificatie Sterke authentificatie Sterke authentificatie

Vergelijking tussen de FedICT authentificatiediensten en de MKDV noden

Er zijn dus verschillende oplossingen mogelijk voor de verschillende vooropgestelde implementatiescenario’s: •

Scenario 2 : Dankzij de bestaande beschikbare FedICT authentificatiediensten, moet de authentificatie (tot op een zeker niveau van vertrouwen) geïmplementeerd worden in het systeem om toegang te kunnen verlenen aan belangrijkere functionaliteiten in het MKDV systeem. Deze authentificatie is mogelijk voor zowel de particulieren alsook voor de bedrijven en de mandatarissen. Procedures voor het authentificatiebeheer van externe gebruikers zijn beschikbaar bij FedICT. Totdat het systeem van de elektronische identiteitskaart volledig is uitgerold wordt voor de particulieren een authentificatiesysteem met token voorlopig als voldoende beschouwd voor die functionaliteiten die een sterke authentificatie vereisen.

•

Scenario 3 : De integratie met de authentificatiesystemen van niveau 3 geleverd door FedICT (elektronische identiteitskaart voor de burgers, certificaten voor de bedrijven) laat een sterke authentificatie toe van alle vraagstellers via het volgen van strikte en gecentraliseerde beveiligingsbeheersprocedures. Het MKDV systeem beschikt op die manier over een voldoende graad van vertrouwen om meer geavanceerde functionaliteiten te leveren aan de vraagstellers op basis van de beschikbare authentificatiemethoden en de opgelegde beveiligingsprocedures en -politiek.

Vertrouwelijk

© FOD Financiën


Rekening houdend met de planning voor de realisatie van het MKDV systeem en van de door FedICT aangeboden diensten zal de authentificatie van de vraagstellers slechts noodzakelijk zijn vanaf fase 4 voor bepaalde kanalen van het MKDV programma en nog later voor de andere kanalen. Bijgevolg zal het MKDV systeem zich in ieder geval kunnen baseren op scenario 2 en eventueel op scenario 3, afhankelijk van de implementatie van andere projecten zoals de digitale identiteitskaart.

Voor de gebruikers van het systeem volstaat identificatie niet. Het is essentieel dat iedere gebruiker (operator, agent, beheerder, en andere) positief geauthentificeerd wordt door het systeem of door een ander systeem waarmee een vertrouwensrelatie (trust) bestaat zoals bijvoorbeeld een ID management systeem. Iedere transactie en/of functie mag enkel toegankelijk zijn voor een geauthentificeerde gebruiker. Iedere persoon met toegang tot het systeem moet een persoonlijke gebruikersaccount gebruiken. Het gebruik van een generieke gebruikersaccount of gebruikersaccountgroep wordt niet toegelaten in het MKDV systeem. Bovendien moet een legale boodschap het gebruikskader verduidelijken alvorens een gebruiker zich verbindt met het systeem. Het beheer van de accounts en identiteiten moet verlopen volgens strikte en regelmatig gecontroleerde beveiligingsprocedures en -beleid. Deze aspecten worden in iets meer detail besproken in paragraaf 4.2 BeveiligingsbeheerIedere account moet worden beveiligd door een kwaliteitsvol wachtwoord (lengte en complexiteit) dat regelmatig wordt veranderd volgens een gedefinieerde toekenningsprocedure en een wachtwoordbeleid.

Voor de verschillende implementatiescenario’s en fasen die voor het systeem werden gedefinieerd zijn er verschillende oplossingen mogelijk: •

Scenario 1 : De authentificatie is geïntegreerd in het MKDV systeem. Het beheer van de gebruikers wordt ook volledig binnen het project gerealiseerd. Dit functioneel beheer werd gedefinieerd in de use cases O1 tot O7 van de functionele architectuur. Dit scenario vereist een implementatie van gebruikersbeveiligingsprocedures specifiek voor het systeem.

•

Scenario 2 : In geval dat het MKDV systeem intern wordt ontwikkeld zal de authentificatie van de gebruikers gebeuren via een integratie met het CCFF project. CCFF stelt immers een gebruikersauthentificatie voor via een verbinding met het bestaande LDAP systeem. In het kader van de implementatie van een commercieel pakket, zal de authentificatie gerealiseerd worden op basis van directe queries naar het LDAP systeem. In dit scenario zullen de use cases O1 tot O7 van de functionele architectuur gerealiseerd worden door de LDAP systeembeheerders en toegankelijk worden gemaakt via de door CCFF geleverde diensten. De gebruikersbeveiligingsprocedures zullen niet op niveau van het systeem worden gedefinieerd, maar op het niveau van het LDAP beheer, toegankelijk via CCFF diensten. Niettemin moet er een formeel systeem van gebruikersaanvragen en goedkeuringen worden geïmplementeerd.

•

Scenario 3 : In dit scenario wordt de gebruikersauthentificatie gerealiseerd via het ID management systeem. Het MKDV systeem zal een vertrouwensrelatie opzetten met het ID management systeem, dat onder meer de gebruikers, hun attributen (rollen en profielen in MKDV, enz.) en hun toegang omvat. In dit scenario zullen de use cases O1 tot O7 van de functionele architectuur worden overgedragen naar het ID management programma. Het systeem van de aanvragen (creatie, veranderingen, enz.) zal deel uitmaken

Vertrouwelijk

© FOD Financiën


van de “workflow” applicatie die een onderdeel vormt van het ID management systeem. Gebruikersbeveiligingsprocedures worden gedefinieerd op niveau van het ID management programma en overgenomen door het MKDV programma. Rekening houdende met de planning voor de realisatie van het MKDV systeem en van het ID management systeem zal de fase 1 van het MKDV programma zich moeten baseren op scenario 2. Vanaf fase 2 zal er echter een integratie met het ID management systeem moeten worden gerealiseerd (scenario 3). Scenario 1 moet vermeden worden voor de authentificatie van gebruikers.

! (#%

( ( $ $+

!

( &

+ "

- %)% *

Voor de vraagstellers zullen directe autorisaties tot de functionaliteiten van het systeem beperkt blijven tot de selfservice die beschikbaar is via het portaal. In alle andere gevallen zal de vraagsteller geen directe toegang hebben tot het systeem en zal het de gebruiker zijn die via de beschikbare functionaliteiten een antwoord op de vraag zal formuleren. Nochtans moet er een autorisatiesysteem voor de functionaliteiten van het MKDV systeem worden geïmplementeerd . Om voor de hand liggende beheersredenen zal het systeem voor het beheer van de autorisaties gemeenschappelijk of gelijkaardig moeten zijn voor de externe gebruikers (vraagstellers) en voor de interne gebruikers. De algemene vereisten voor de autorisaties zijn gedefinieerd in punt 4.2 Beveiligingsbeheer. Afhankelijk van het type van de vraagsteller (particulier, bedrijf, mandataris, enz.) en het niveau van de authentificatie in het systeem (anoniem, geïdentificeerd, geauthentificeerd, sterk geauthentificeerd) moeten de autorisaties verschillend zijn.

Er zijn verschillende oplossingen mogelijk voor de verschillende vooropgestelde implementatiescenario’s: •

Scenario 1 : Het beheer van een in het systeem geïntegreerde database van alle vraagstellers is praktisch niet haalbaar in dit scenario. Enkel de functionaliteiten die anoniem toegankelijk zijn zouden hierin kunnen worden opgenomen, hetgeen zou leiden tot een zeer beperkt autorisatiesysteem.

•

Scenario 2 : De rollen verbonden aan een vraagsteller zijn ook voorzien in de door FedICT beheerde authentificatie diensten. Toch moet ook een autorisatiesysteem gebaseerd op de rollen van de vraagsteller in het MKDV systeem worden geïmplementeerd om die rollen te linken aan de autorisaties van de systeemfunctionaliteiten : de use cases O8 en O9 zullen dus lokaal worden gerealiseerd. Regels en procedures voor het toewijzen van rollen aan de vraagstellers moeten worden ontwikkeld om de noodzakelijke informatie te integreren in de gebruikerssystemen die door FedICT centraal worden beheerd (use cases O10 tot O14).

•

Scenario 3 : Dit scenario is vergelijkbaar met het vorige scenario : de rollen en profielen van de externe gebruikers (vraagstellers) worden geïntegreerd in de door FedICT geleverde sterke authentificatiesystemen. Niettemin moeten de toegangsrechten aan rollen en profielen worden verbonden. Dit wordt gerealiseerd door de integratie van het toegangsbeheer in het interne ID Management project d.i. in meer detail beschreven in scenario 3 voor toegang voor MKDV gebruikers). De beveiligingsbeheersprocedures worden

Vertrouwelijk

© FOD Financiën


centraal gedefinieerd (FedICT) en gevolgd door het MKDV programma. Wel moet er een akkoord worden gemaakt over de procedures voor het toekennen van de rollen (use cases O10 tot O14). Rekening houdende met de planning voor de realisatie van het MKDV systeem en van het ID management systeem, alsook van de door FedICT aangeboden diensten, zal het toegangsbeheer slechts nodig zijn vanaf fase 4 van het MKDV programma (specifieke interacties) en zal het zich moeten baseren op scenario 2 of scenario 3, afhankelijk van de vooruitgang van het uitrollen van de elektronische identiteitskaart. Voor fase 1-3 van het programma is het toegangsbeheer voor de vraagstellers zeer beperkt (anoniem en identificatie).

Een autorisatiesysteem voor de functionaliteiten van het systeem moet worden geïmplementeerd op basis van een bestaande « nood of behoefte om te weten » (« Need to Know »). De gebruikers moeten immers enkel toegang hebben tot die functionaliteiten die ze nodig hebben om de aan hun toegewezen taken te kunnen uitvoeren. De beste manier om een eenvoudig te beheren en te onderhouden autorisatiesysteem te implementeren is een systeem van rollen en profielen, die toegang geven tot hieraan gekoppelde functionaliteiten. De gebruikersaccounts moeten bijna nooit direct aan autorisaties worden gelinkt. De accounts zijn verbonden met rollen die dan op hun beurt zijn gekoppeld aan de toegangsrechten tot de functionaliteiten van het systeem. Het direct toekennen van toegangsrechten aan gebruikers doet zich enkel in zeer beperkte en bepaalde situaties voor. Tevens moeten er regels worden opgesteld voor het definiëren van welke rollen en toegangsrechten onverenigbaar met elkaar zijn (principe van scheiding van bevoegdheden). Deze regels moeten worden geïmplementeerd in het toegangsbeheersysteem zodat het technisch onmogelijk wordt om rechten vrij te verzamelen. Het toegangsbeheersysteem moet immers over een logische hiërarchische structuur beschikken voor het beheer van de verzameling van toegangsrechten. De op heden meest gebruikte mogelijkheid is die van het maximum privilege: indien een gebruiker tot meerdere groepen behoort zal hij op een bepaalde functionaliteit de rechten hebben van de groep met de hoogste privileges. Het toegangsbeheer, de « rapportering » alsook het regelmatig nazien van de toegangsrechten zijn ook essentiële elementen in een goed autorisatiebeheer. Deze punten worden besproken in punt 4.2 Beveiligingsbeheer.

Voor de verschillende implementatiescenario’s en fasen die voor het systeem werden gedefinieerd, zijn er verschillende oplossingen mogelijk : •

Scenario 1 : Het beheer van de autorisaties is volledig geïntegreerd in het MKDV systeem. Dit functioneel beheer werd gedefinieerd in de use cases O8 tot O14 van de functionele architectuur. Een toegangsbeheer systeem op basis van rollen moet worden geïmplementeerd in het systeem. Bovendien vereist dit scenario de implementatie van specifieke beheersprocedures van de toegangsrechten.

•

Scenario 2 : De rollen verbonden aan de gebruikers worden door het LDAP systeem toegekend, ofwel op een directe manier indien het MKDV systeem gebaseerd is op een commercieel pakket, ofwel via de door het CCFF platform geleverde authentificatiediensten indien het MKDV systeem in het CCFF wordt geïntegreerd. Niettemin moet er ook een autorisatiesysteem gebaseerd op rollen worden geïmplementeerd in het MKDV systeem om de rollen die aan de gebruikers zijn toegekend te koppelen aan de functionaliteiten van het systeem: de use cases O8 en O9 zullen dus lokaal worden gerealiseerd. De regels en procedures voor het toewijzen van rollen aan gebruikers moeten worden ontwikkeld (use cases O10 tot

Vertrouwelijk

© FOD Financiën


O14) in overeenstemming met het LDAP systeembeheer. Zoals in het voorgaande scenario moeten het toegangsbeheer en de hiermee verbonden procedures specifiek voor het MKDV systeem worden geïmplementeerd. •

Scenario 3 : In dit laatste scenario worden de gebruikers en hun rollen en profielen geïntegreerd in het ID management systeem. De use cases O10 tot O14 van de functionele architectuur alsook de use cases O8 en O9 met betrekking tot het toegangsbeheer worden overgedragen naar het ID management programma.

Vertrouwelijk

© FOD Financiën


Het ID Management programma heeft een aanpak gedefinieerd die door alle toepassingen die zich willen integreren in dit centraal toegangsbeheer systeem moet worden gevolgd Er moet een specifiek referentiesysteem worden opgezet via een gebruikersforum bestaande uit leden van het ID management project alsook van het MKDV systeem met als doel het definiëren van: o

de gebruikersrollen

o

een toegangsmatrix, die de toewijzing van de toegangsrechten in functie van de rollen beschrijft

o

de regels rond het beheer van het toekennen van rollen aan de gebruikers

Aanvragen (creatie van een rol, profiel, verandering, enz.) worden beheerd door de work flow toepassing van het ID Management systeem. De beveiligingsprocedures zijn gedefinieerd op niveau van het IDM project en worden door het MKDV project gevolgd. Door de beschikbaarheid van het ID Management systeem, zal het scenario 2 in fase 1 worden opgenomen en het scenario 3 kan dan vervolgens worden geïmplementeerd vanaf fase 2 van het MKDV programma.

! (#%

( ( $ $+

. # $ $ + %+ "

- /#($# **

Gelijkaardig aan het beheer van de autorisaties tot de systeemfunctionaliteiten, moet de toegang tot de externe gegevens alzo worden beheerd dat de gebruikers en vraagstellers enkel toegang hebben tot de gegevens of informatie die ze nodig hebben voor de uitvoering van hun dagelijkse taken of voor het beantwoorden van de vraag. Het is belangrijk om op te merken dat deze gegevens de eigendom zijn van andere systemen die zelf instaan voor het bepalen van het gewenste beveiligingsniveau op basis van het kritieke karakter van die gegevens. In dit perspectief ligt de verantwoordelijkheid voor het beheren en toekennen van toegang tot deze data aan gebruikers en vraagstellers bij de eigenaar van deze data en wordt dit niet verschillend beheerd door het MKDV systeem. Bijgevolg is de toegang tot externe data voor de vraagstellers en de gebruikers in de volgende oplossingen slechts eenmaal beschreven.

Er zijn verschillende oplossingen mogelijk voor de verschillende vooropgestelde implementatiescenario’s: •

Scenario 1 : Het beheer van de autorisaties tot toegang van de externe gegevens is volledig geïntegreerd in het MKDV systeem. Het beheer wordt gerealiseerd op basis van dezelfde systemen en procedures die werden gedefinieerd voor de toegang tot de functionaliteiten. De externe systemen geven algemene toegangsrechten aan het MKDV systeem op basis van service accounts.

•

Scenario 2 : Zoals in het vorige scenario wordt de toegang tot de externe gegevens gerealiseerd zonder validatie door het MKDV systeem. Er worden in dit geval echter wel unieke identificatiemiddelen (UID) van de gebruikers en vraagstellers gebruikt voor het opvragen van de externe data, hetgeen een betere traceerbaarheid door de externe systemen toelaat. Het toekennen van de toegang gebeurt gedeeltelijk in het MKDV systeem maar ook in de andere systemen dankzij de integratie met de CCFF/LDAP (gebruikers) en de FedICT (vraagstellers) systemen.

•

Scenario 3 : In het laatste scenario krijgen de gebruikers en de vraagstellers toegang tot de externe data via het gebruik van de diensten (e-Services of klassieke toegang) van de andere toepassingen. Het zijn deze

Vertrouwelijk

© FOD Financiën


externe applicaties die de toegang en de autorisaties tot hun data beheren. Het ID Management systeem wordt bovendien transversaal gebruikt om het beheer van de toegang tot al deze applicaties te vereenvoudigen. Het toekennen van de toegang gebeurt in de systemen waarvan de gegevens worden geraadpleegd of in het ID Managementsysteem indien dit beschikbaar is. Het gebruik van externe data is slechts gepland vanaf fase 4 voor de specifieke interacties via bepaalde kanalen (email, correspondentie en telefoon) en later ook voor de andere kanalen (fase 5 voor persoonlijk onthaal en fase 6 voor de self-service). Bijgevolg moeten de basisvereisten beschikbaar zijn voor de implementatie van scenario 3

0

#

#' #"

Enkel de functionele traceerbaarheid wordt in dit gedeelte besproken. Het opvolgen en bijhouden van logbestanden op technisch vlak (netwerk, besturingssysteem, enz.) wordt besproken in de analyse van de beveiliging van de technische architectuur. De transacties van de gebruikers alsook de vragen van de vraagstellers moeten worden gecontroleerd op het vlak van de beveiliging op applicatieniveau. Het zijn immers niet enkel de operationele functionaliteiten die moeten worden gelogd, maar ook alle onderliggende beheersfunctionaliteiten. Bijvoorbeeld, het beheer van de gebruikers moet kunnen worden getraceerd (creatie, wijziging en verwijderen van gebruikers of rollen). Om de potentiële pogingen vanwege externe (vraagstellers) en interne gebruikers tot het verkrijgen van nietgeautoriseerde toegang (tot de verschillende functionaliteiten alsook de gegevens) te kunnen ontdekken moet bovendien de toegang tot de applicatie ook worden gecontroleerd (opvolgen van aanvaarde en geweigerde verbindingen). De logbestanden moeten op een regelmatige basis worden nagezien door specifiek hiervoor geautoriseerde gebruikers. Bovendien mogen de logbestanden in ieder geval niet kunnen worden gewijzigd of verwijderd , zelfs niet door de systeembeheerders. Ze moeten worden opgeslagen en gearchiveerd om mogelijke misbruiken later te kunnen inspecteren. Het nakijken van de logbestanden moet plaatsvinden in overeenstemming met de controle en monitoring procedures en beleid (zie punt 4.2Beveiligingsbeheer).

De logbestanden moeten voldoende informatie bevatten om de bron van de transactie en de uitgevoerde acties eenduidig te kunnen identificeren. Daarom moeten de volgende elementen hierin zeker worden opgenomen: •

Datum en tijdstip van de actie

•

Gebruiker en/of vraagsteller betrokken in de actie

•

Rol van de gebruiker/vraagsteller

•

Type van de gebruikte functionaliteit

Tevens kunnen in functie van het kritieke karakter van de transactie en van de gegevens nog bijkomende elementen in de logbestanden worden opgenomen •

Referenties naar de betrokken data

Vertrouwelijk

© FOD Financiën


•

Waarde van de gegevens voor de transacties (in geval de transactie gegevens wijzigt).

Gegeven de verschillende implementatiescenario’s en fasen die voor het systeem werden gedefinieerd zijn er verschillende oplossingen mogelijk : •

Scenario 1 : Alle traceermogelijkheden/functionaliteiten moeten mee in het MKDV systeem worden geïntegreerd. Procedures voor het nazien van de logbestanden moeten specifiek voor het systeem worden geïmplementeerd

•

Scenario 2 : In het geval van specifieke ontwikkeling zal het MKDV systeem zich mee integreren in het CCFF platform, welke over een « logging dienst » voor toepassingen beschikt die toelaat om de logbestanden van de verschillende applicaties/toepassingen te centraliseren. Monitoring moet dus mee worden geïntegreerd in het CCFF model. Indien een commercieel pakket wordt gebruikt zullen de traceermogelijkheden mee in het MKDV systeem geïntegreerd zijn. Procedures voor het nakijken van de logbestanden moeten specifiek voor het systeem worden geïmplementeerd om te kunnen definiëren welke evenementen volgens welke frequentie moeten worden nagekeken

•

Scenario 3 : In het laatste scenario wordt de traceerbaarheid op een centrale manier gerealiseerd via het ID Management systeem. De centrale procedures voor het nazien van de logbestanden kunnen in dat geval ook voor het MKDV systeem worden toegepast

Voor ieder scenario is een integratie tussen het functionele monitoring systeem en het technische monitoring systeem aan te raden. Bovendien kan deze monitoring eventueel worden opgenomen in een groter project dat de traceerbaarheid van de verscheidene toepassingen en systemen binnen de FOD Financiën bestudeert. In de eerste fases van de implementatie kan scenario 2 mogelijk worden gebruikt Bij de latere fases (3 of 4) moeten dan de vereiste systemen en procedures voor het uitvoeren van scenario 3 beschikbaar zijn.

Vertrouwelijk

© FOD Financiën


0

1

0

+ &$ $ +

1

# %#! !!#

De analyse van de beveiliging van de technische architectuur is gestructureerd volgens de verschillende infrastructuurlagen uit ons beveiligingsmodel : databanken, platformen, netwerk en fysieke omgeving. Voor elk van deze lagen definiëren wij in dit hoofdstuk de beveiligingsvereisten. De technische architectuur integreert de informatica-infrastructuur van het MKDV systeem in de huidige en toekomstige projecten en standaarden van de FOD Financiën. De integratie met de netwerkarchitectuur, het CCFF model, de Atlas infrastructuur en de gemeenschappelijke fysieke infrastructuur beperkt op deze manier de mogelijke beveiligingsoplossingen. Daarom zijn de scenario’s vermeld in het vorige hoofdstuk niet van toepassing voor de informatica-infrastructuur. Omdat het MKDV programma zich nog maar in de fase van de voorstudie bevindt, is het detailniveau van de technische architectuur beperkter en met weinig specifieke technologische keuzes. De noden op het vlak van de beveiliging die in dit hoofdstuk worden beschreven blijven daarom generiek en moeten in een later stadium tijdens de implementatie van het MKDV systeem nog worden vertaald in meer concrete technische voorstellen.

Om de informatie van het MKDV systeem te beschermen en directe toegang of aanvallen op de databank te vermijden moeten er beveiligingstandaarden op het niveau van de databank worden ontwikkeld en geïmplementeerd Deze standaarden moeten ondermeer de volgende aspecten behandelen : •

Verzekeren dat geen enkele eindgebruiker of applicatiegebruiker op het niveau van de databank is gedefinieerd.

•

Implementeren van strikte controles op het niveau van de database accounts en hun wachtwoorden.

•

Beperken van het aantal database accounts op het systeem en van het aantal systeembeheerders.

•

Verzekeren dat de door de applicatie gebruikte database accounts niet beschikken over te uitgebreide toegangsrechten.

•

Verwerpen van aanvragen van niet-geautoriseerde systemen (andere dan de applicatieserver en beheerssystemen).

•

Verzekeren dat de directe toegang tot de gegevens van buiten de applicatie zeer beperkt is (bijvoorbeeld het gebruik van SQL queries of ODBC connecties)

•

Opvolgen en registeren van beveiliging gerelateerde systeemacties en van veranderingen aan de database structuur.

•

Verzekeren dat beveiligingspatches en andere updates op een regelmatige basis op de databank servers worden geïnstalleerd.

Vertrouwelijk

© FOD Financiën


Om te vermijden dat de servers kwetsbaar zijn voor gekende of door verkeerde configuratieparameters veroorzaakte problemen, moeten deze adequaat worden beveiligd na de installatie. Voor elk besturingssysteem moeten beveiligingstandaarden worden ontwikkeld die onder meer de volgende domeinen afdekken : •

Authentificeren (beheer van accounts, wachtwoordbeleid, toegang tot geprivilegieerde gebruikers, enz.), en controleren van de toegangsrechten op bestanden, programma’s, processen, enz.

•

Beperken van het aantal accounts en vooral het aantal systeembeheerders op het productiesysteem

•

Verzekeren dat de door de applicatie gebruikte accounts om toegang te krijgen tot het systeem niet over excessieve rechten beschikken.

•

Uitschakelen van alle niet gebruikte en niet nuttige processen op de server.

•

Gebruiken van beveiligde systeembeheerstools (vb. SSH op UNIX)

•

Regelmatig updaten en installeren van patches op het productiesysteem.

•

Monitoring en logging

Een beveiligde netwerkarchitectuur moet er in de eerste plaats voor zorgen dat er een scheiding is tussen de verschillende subnetwerken in functie van het kritieke karakter van de systemen en van de gegevens alsook in functie van de gebruikers die toegang hebben tot de systemen. Daarom moet een systeem dat direct toegankelijk is van op het Internet zeker logisch worden gescheiden van de interne systemen (gebruik van een DMZ). De architectuur van een systeem gebaseerd op de internettechnologie moet in verschillende lagen worden opgesplitst: •

De presentatielaag : webservers waarmee Internet gebruikers zich

verbinden en die statische

informatie publiceren. Deze laag moet worden opgedeeld in functie van de interne en de externe gebruikers. •

De applicatielaag : applicatieservers die de operationele applicatielogica bevatten.

•

De datalaag: databankservers waarop de eigenlijke gegevens zijn opgeslagen In dit type architectuur kunnen enkel de servers in de presentatielaag zich verbinden met op de applicatieservers en zijn deze laatsten op hun beurt de enige die een verbinding kunnen opzetten met de databaseservers.

Vertrouwelijk

© FOD Financiën


De fire walls zijn één van de belangrijkste beveiligingsmiddelen om het eigen netwerk te beveiligen ten opzichte van de andere netwerken die een onvoldoende graad van vertrouwen hebben. Voor de implementatie van het MKDV systeem is een adequaat netwerkbeveilingsontwerp met behulp van fire walls noodzakelijk. Een dergelijk ontwerp bestaat uit verschillende types van fire walls die in serie achter elkaar worden geplaatst alsook het in parallel zetten van identieke fire walls ( om de beschikbaarheid en performantie te kunnen garanderen). Hiernaast dienen de fire walls ook op een adequate wijze te worden geconfigureerd en onderhouden om het netwerk van de FOD Financiën continu te kunnen beveiligen. De volgende aspecten moeten hierbij in acht worden genomen: •

Alle onnodige trafiek moet worden geblokkeerd

•

Het aantal filterregels moet beperkt blijven tot diegene die strikt noodzakelijk zijn om een goede werking te garanderen

•

Het gebruik van generieke objectdefinities (vb. “any”) moet worden vermeden of gecontroleerd

•

De fire wall software moet op regelmatige basis worden geactualiseerd om zich tegen de gekende zwakheden te kunnen beschermen.

•

Het beheer van de fire wall moet strikt worden gecontroleerd (beperking van het aantal consoles, encryptie, authentificatie, enz.).

•

Activering van de logbestanden en monitoring van de beveiliginggerelateerde activiteiten.

Teneinde een voldoende niveau van beveiliging op netwerkniveau te realiseren moet de configuratie van netwerkelementen (routers, switchen, VLANs, enz.) op een adequate manier beveiligd worden en moet er met onder andere de volgende elementen rekening worden gehouden : •

Beperking van de beheersrechten voor netwerkelementen tot enkel geautoriseerd personeel. Enkel de netwerkbeheerders moeten immers in staat zijn om toegang te bekomen tot de configuratie van netwerkelementen en in de mate van het mogelijk moeten de voor systeembeheer gebruikte communicatiemiddelen adequaat beveiligd zijn (encryptie).

•

Implementatie van filters op de actieve componenten zoals de routers en de firewalls. De filters laten toe om het netwerkverkeer te beperken alsook de communicatie tussen systemen die niet met elkaar moeten communiceren.

•

Deactivatie van niet gebruikte netwerkdiensten op de netwerkelementen om die te beschermen tegen niet-geautoriseerde toegang wat mogelijk kan leiden tot wijzigingen in de configuratie of tot beschikbaarheidsproblemen.

•

Regelmatig actualiseren van de software van de actieve netwerkcomponenten (routers, firewalls, enz) om het exploiteren van de gekende beveiligingsgaten te voorkomen.

Vertrouwelijk

© FOD Financiën


•

Het bijhouden van logbestanden met betrekking tot de beveiliginggerelateerde activiteiten. De monitoring van de logbestanden moet overeenstemmen met de bestaande logging en monitoring procedures.

In het algemeen moeten de netwerkcomponenten (data en telefonie) worden geconfigureerd en beheerd volgens de intern gedefinieerde beveiligingsstandaarden of volgens de internationaal geaccepteerde referentiestandaarden (vb. NIST - National Institute of Standards and Technology).

Gevoelige informatie moet worden beveiligd worden wanneer het over een netwerk wordt verzonden. Deze informatie moet worden versleuteld (geëncrypteerd) zodat ze niet kan worden onderschept door interne of externe niet geautoriseerde personen. Voor het MKDV systeem moet de authentificatie procedure worden versleuteld voor zowel de interne als de externe gebruikers. De encryptie zal worden gerealiseerd tussen het “client” systeem (werkpost of persoonlijke computer) en de webserver via het https protocol op het moment van de uitwisseling van authentificatie-informatie (user ID, wachtwoord, certificaat, enz.). Bovendien moet de authentificatie en sessie gebonden informatie die bewaard wordt op het « client » systeem (cookie) eveneens worden versleuteld. Wanneer de functionaliteiten voor de specifieke interacties voor de vraagstellers (burgers, bedrijven en mandatarissen) zullen zijn geïmplementeerd , zullen die ook toegang hebben tot de vertrouwelijke informatie die aan hun dossier is verbonden. Deze informatie moet eveneens volgens dezelfde methoden worden versleuteld.

Een adequaat niveau van beveiliging voor een systeem kan maar worden gerealiseerd als de logische en de fysieke beveiligingsmaatregelen op een correcte wijze worden gecombineerd. Dit hoofdstuk legt de vereisten qua fysieke controles vast voor de infrastructuur van het MKDV project. Wij hebben drie verschillende locaties onderscheiden die specifieke controles vereisen : de computerzalen, de contact centers en de zones voor persoonlijk onthaal van de vraagstellers. Wij merken op dat enkel de aspecten verbonden aan de beveiliging van de informatie hieronder worden beschreven. De beveiliging van de fysieke personen valt onder de verantwoordelijkheid van de IDPBW (Interne Dienst voor Preventie en Bescherming op het Werk). Alle systemen en componenten van het project moeten fysiek worden beschermd in overeenstemming met het beleid en de van kracht zijnde procedures binnen de FOD Financiën.

Vertrouwelijk

© FOD Financiën


De computerzalen zijn gedefinieerd als plaatsen waar de technische infrastructuur van het MKDV project (servers, netwerkcomponenten, telefonie, enz.) zich bevindt. De eindgebruiker infrastructuur (PC, telefoon, enz) bevindt zich niet in de computerzalen.

Niet-gecontroleerde toegang tot de componenten en de systemen kan niet geautoriseerde personen toelaten om toegang te krijgen tot kritieke informatie, om de systemen te manipuleren of om de infrastructuur (bewust of onbewust) te beschadigen. Daarom moeten alle systemen alsook de mediaopslagruimten adequaat worden beschermd tegen niet-geautoriseerde toegang. De volgende beveiligingsmaatregelen moeten onder andere worden geïmplementeerd : •

Elektronische toegangscontrole (individuele badges, code)

•

Goed beveiligde toegangsdeuren

•

Keuze voor de plaats van de computerzaal in het gebouw (aanwezigheid van ramen, dak, enz.)

•

Bescherming van componenten in afgesloten kasten (racks).

•

Inbraakalarm

•

Procedures voor de begeleiding van bezoekers en contractanten

•

Procedures voor de schoonmaak onder controle van de computerzaal

Bovendien moet alle toegang tot de computerzaal worden geregistreerd en opgeslagen in een logbestand zodat dit bestand op regelmatige basis en in geval van een incident kan worden nagekeken

Natuurrampen, branden, elektriciteitspannes en andere externe problemen kunnen onherstelbare schade toebrengen aan de infrastructuur en de beschikbaarheid van het systeem in gevaar brengen. Dus moeten specifieke maatregelen ter bescherming van de computerzalen worden geïmplementeerd : •

Brand- en rookdetectie

•

Manuele en automatische brandblussystemen

•

Airconditioning (temperatuur en vochtigheidsregeling)

•

Vocht- en waterdetectoren

•

Elektrische noodsystemen (UPS en generators)

Deze controles, die de impact van omgevingsproblemen verkleinen, moeten worden gekoppeld aan de continuïteitsmaatregelen (bijv. herstelplan) die in het volgende hoofdstuk worden beschreven.

Vertrouwelijk

© FOD Financiën


Voor het (de) contact center(s) moeten eveneens controlemaatregelen worden geïmplementeerd om de fysieke toegang te beperken tot de geautoriseerde personen: •

Elektronische toegangscontrole (individuele badges)

•

Procedures voor de begeleiding van externen

De fysieke toegang tot deze plaatsen moet eveneens in een logbestand worden bijgehouden en opgeslagen zodat dit bestand op regelmatige basis en in geval van een incident kan worden nagekeken Het persoonlijk onthaal van de vraagstellers moet op een gecontroleerde manier plaatsvinden om te vermijden dat externen toegang zouden kunnen krijgen tot de werkposten en vertrouwelijke informatie. Daarom moeten er procedures worden ontwikkeld en geïmplementeerd om het gedrag van het personeel met betrekking tot de veiligheid van de informatie ten aanzien van de vraagstellers te sturen. Deze procedures moeten aan het personeel worden uitgelegd en gecommuniceerd via een bewustmakingsprogramma, zoals in het volgende hoofdstuk wordt beschreven.

0

+ &$ $%' " #

De aspecten met betrekking tot de informatiebeveiliging moeten een onderdeel vormen van het operationeel beheer van het MKDV systeem en moeten overeenstemmen met een beveiligingsbeheersysteem. Om een systeem zoals de MKDV applicatie op een veilige manier te beheren moet er een beveiligingsbeheersysteem aanwezig zijn teneinde een maximum aan controle op zowel de functionele als de technische aspecten van het informaticasysteem te kunnen uitoefenen. Een dergelijk systeem moet onder meer de volgende componenten omvatten: •

Beveiligingsbeleid Het management moet op vlak van de informatiebeveiliging een duidelijke visie en een sterk engagement tonen via de creatie en de opvolging van een adequaat beveiligingsbeleid. Dit beleid moet worden goedgekeurd, gepubliceerd en gecommuniceerd aan alle betrokken partijen binnen de organisatie (FOD Financiën). Ze moet de algemene aanpak inzake het beheer van de informatiebeveiliging beschrijven en vastleggen. De volgende punten moeten hierin minimaal worden opgenomen en zullen in de volgende paragrafen gedeeltelijk nog uitvoeriger worden toegelicht: o o o o o o o o

Vertrouwelijk

Een definitie van de informatiebeveiliging en het belang ervan voor de organisatie Het in regel zijn met de legale en de contractuele vereisten Vastleggen van de verantwoordelijkheden Klassering van informatie Opleidingsvereisten verbonden aan de informatiebeveiliging Beheer van de continuïteit en capaciteit Gevolgen voor het schenden van het beveiligingsbeleid Referenties naar documenten die het beleid verder uitwerken: procedures, standaarden, enz.

© FOD Financiën


•

Organisatie, rollen en verantwoordelijkheden Het is essentieel om de verschillende betrokken partijen, hun rol en verantwoordelijkheden ten opzichte van de systemen en de gegevens te verduidelijken, zodat op basis hiervan de verantwoordelijkheden op vlak van de informatiebeveiliging kunnen worden vastgelegd Een verantwoordelijke voor de beveiliging van informatie moet worden aangeduid om alle informatiebeveiligingstaken te superviseren, zowel tijdens de implementatie als tijdens de operationele fase van het MKDV programma.

•

Risicobeheer Een systeem voor het beheer van risico’s moet opgezet worden om de beveiligingsrisico’s verbonden aan het project tijdig te kunnen identificeren, hun belangrijkheid in te schatten en een beslissing te nemen over de manier waarop het risico moet worden beheerd. Uiteindelijk moet dat leiden tot de implementatie van de noodzakelijke adequate beveiligingscontroles.

•

Beveiligingsprocedures en -standaarden Op basis van het beveiligingsbeleid moeten er beveiligingsprocedures en -standaarden worden ontwikkeld om de informatiebeveiliging om een gecontroleerde wijze te beheren tijdens de implementatie alsook tijdens de operationele fase van het MKDV project: o

Beheer van de gebruikers en hun toegang tot het systeem

o

Systeembeheerrechten (beperking van het aantal systeembeheerders, gebruik van beveiligde protocols en tools)

o

Monitoring en alarmen voor het detecteren van potentiële beveiligingsincidenten

o

Gebruik van beveiligingstools (vb. antivirus) om zich te beschermen tegen wijd verspreide en populaire vormen van elektronische aanvallen.

o

Beheer van technische en functionele veranderingen

o

Detectie en beheer van beveiligingsincidenten

o

Documentatiestandaarden voor de architectuur, systemen en netwerk.

o

Technische

configuratiestandaarden

voor

de

databanken,

besturingssystemen,

netwerkcomponenten, enz. o

Standaarden voor fysieke beveiliging van de systemen en de informatie

•

Beheer van de interacties met derden voor het onderhouden van het niveau van beveiliging en met de beveiligingswereld om een coherent en actueel zicht te krijgen op de potentiële beveiligingsproblemen.

•

Opleiding en bewustmaking Voor alle gebruikers van het MKDV systeem moet een bewustmakingsprogramma worden opgesteld over de algemene beveiligingsaspecten en –problemen, alsook specifieke in het MKDV systeem aanwezige risico’s. In de algemene gebruikersopleiding moeten eveneens basisnoties van logische en fysieke beveiliging worden geïntegreerd. Bovendien is een bijkomende specifieke opleiding voor de systeembeheerders (van de toepassingen en de infrastructuur) noodzakelijk, aangezien zij in de praktijk de beveiliging van het systeem beheren.

Vertrouwelijk

© FOD Financiën


•

Beheer van de continuïteit en capaciteit Om continuïteits- en capaciteitsproblemen te vermijden en om het MKDV systeem te kunnen herstellen in geval van een belangrijke panne of ramp moeten continuïteitsaspecten mee opgenomen worden in het risicobeheerssysteem. Tevens moet er een aangepast continuïteits- of herstelplan geïmplementeerd worden alsook de noodzakelijke maatregelen inzake beschikbaarheid, continuïteit en beheer van de capaciteit.

Bij deze continuïteitsmaatregelen moet de klemtoon liggen op het regelmatig uitvoeren van back-ups van gegevens alsook van de configuratie van de servers, de netwerkcomponenten en andere in de architectuur aanwezige elementen. De back-up frequentie kan variëren per type data : dagelijks voor de gegevens ofvolgens de veranderingen voor de configuraties die in de tijd relatief stabiel blijven. De opslagmedia moeten eveneens op een adequate wijze worden beschermd en opgeslagen op een andere locatie dan de systemen waarvoor reeds een back-up is gedaan. Strikte back-up procedures moeten eveneens worden ontwikkeld en geïmplementeerd en moeten onder meer de volgende aspecten omvatten: de frequentie, het type van de back-up, de retentie periode, het beheer van de opslagmedia, de fysieke en logische beveiliging van de back-ups, enz.

De ontwikkelingsmethodologie voor het MKDV systeem moet tevens beveiligingsaspecten bevatten in alle belangrijke ontwikkelingsfases: • Analyse : risicoanalyse en haalbaarheidstudie rond de beveiliging • Definitie van de beveiligingsnoden en -vereisten • Technisch en functioneel beveiligingsontwerp • Ontwikkeling: veiligheid van de broncode, versiecontrole, scheiding en controle van de verschillende omgevingen, … • Gegevensvalidatie : alle door het systeem behandelde data moeten worden gecontroleerd op integriteit en het type van de gegevens. Deze controles zijn eveneens van toepassing op de interfaces van het MKDV systeem met de andere systemen (CCFF, FedICT, enz.) • Opleiding : beveiligingsaspecten in de opleiding voor de ontwikkelaars en andere in het project betrokken partijen • Testen: beveiligingstesten / interne en externe audits • In productie stelling en opvolging: operationeel beheer van de informatiebeveiliging, opleiding en bewustmaking.

Vertrouwelijk

© FOD Financiën


Voor de verschillende implementatiescenario’s en fasen die voor het systeem werden gedefinieerd zijn er verschillende oplossingen mogelijk : •

Scenario 1 : Een beveiligingsbeheerssysteem moet specifiek voor het MKDV project worden ontwikkeld. Dit systeem moet gestoeld zijn op een gestructureerde aanpak, gebaseerd op erkende internationale en/of Europese beveiligingsstandaarden op vlak van de aanpak, de inhoud, de analyse en het risicobeheer. Ontwikkeling- en operationele procedures moeten tevens in het beveiligingsbeheerssysteem worden opgenomen.

•

Scenario 2 : Een beveiligingsbeheersysteem moet specifiek voor het MKDV project worden ontwikkeld Er was immers op het moment van de studie geen enkel formeel beveiligingsbeheersysteem aanwezig binnen de FOD Financiën. Niettemin werden er reeds enkele beleidsregels ontwikkeld en moeten dievoor het MKDV project worden gebruikt. Zoals voor scenario 1 moet het beveiligingsbeheersyteem beschikken over een gestructureerde aanpak die is gebaseerd op erkende internationale en/of Europese standaarden.

•

Scenario 3 : Het beveiligingsbeheersysteem van het ID Management programma (« Information Security Management ») wordt gebruikt als referentie voor het beheer van de beveiliging van het MKDV systeem. De beveiligingsorganisatie zal zich immers baseren op de structuur en organisatie van het beveiligingsbeheer van het ID Management project. Niettemin moeten er nog specifieke procedures met betrekking tot operationeel beheer en ontwikkeling, controles alsook bepaalde rollen en verantwoordelijkheden voor het MKDV systeem worden ontwikkeld

De implementatie van scenario 3 moet mogelijk zijn in fase 2 van het project. Daarom is de ontwikkeling van een beveiligingsbeheersysteem voor het beveiligingsbeheer tijdens de voorgaande fases niet aan te raden. Enkel de ontwikkeling van procedures, gebaseerd op de bestaande beleidsregels, kan in de eerste fase plaatsvinden.

Vertrouwelijk

© FOD Financiën


2

-

De implementatie van het MKDV systeem gebaseerd op scenario 1, waarbij het beheer en alle beveiligingsfunctionaliteiten mee in het systeem moeten worden geïntegreerd, moet absoluut worden vermeden voor alle aspecten van deze analyse. Een dergelijke implementatie zou immers ingaan tegen de hele strategie van de standaardisatie van de systemen van de FOD Financiën en bovendien een belangrijke meerkost met zich meebrengen. Het is niet de rol van een programma zoals het MKDV systeem om een volledig beveiligingsbeheersysteem op te zetten voor eigen gebruik. Een dergelijk beheer moet onderdeel uitmaken van een grotere visie op informatiebeveiliging binnen de FOD Financiën. Het is daarom noodzakelijk om de beveiliging te implementeren door die maximaal te integreren met de bestaande (scenario 2) en toekomstige (scenario 3) systemen en organisaties. De keuze voor een maximale integratie zoals in de oplossingen van scenario 3 is voorzien laat een standaardisatie van de procedures en systemen toe, wat zal leiden tot een verhoogd niveau van de beveiliging alsook tot een lagere kost voor het MKDV programma zowel op vlak van de ontwikkeling en de implementatie als op het vlak van operationeel beheer. Een samenvatting van de beveiligingsoplossingen alsook hun plaats in de volledige planning van het MKDV project kan in het onderstaande model worden teruggevonden.

Vertrouwelijk

© FOD Financiën


FOD Financiën (6

% &4 &

6 (

5

'# ( (

4 # #5 -

3 '

&

#

4

'# ( (

-

3 '

&

#

(

' ' (

#

'(

' '

#

'# ( (

3 '

'( ' '

35

'(

' '

(

#

'(

' '

' '

'(

#

(

(

#

(

#

% &

'(

#

! " # $

# # # ( % & #,#

# ''

#

+

#

' '

)( ( % & ' ' % &

)( ( ' ' % &

)( ( ! ' ' % &

)( ( ' '

)( ( ' '

' ' #

)( ( % & ' ' % &

)( ( ' ' % & ' *

)( ( ! ' ' % & ' *

)( ( ' '

)( ( ' '

#

'

3

'

2 .

(' % &

('' ' % &

.

'/ ' 0( 11(

-

(#

('' '

(' '# 3

(' '#

% &

-1 -

« Apprentissage »

Vertrouwelijk

% &

-2-

« Centraliser et gérer les flux »

© FOD Financiën

#

( # '( #

- 3-

-4-

« Utiliser les acquis »

« Gérer les interactions spécifiques »

#1

- 5-

.

('

-6-

« Développer la pro« Développer l’accueil personnalisé et intensifier les activité et les potentialités du self service » opérations front office »


3 3

4

5% +

!%

%%

De volgende tabel geeft een overzicht van de use cases die worden vermeld in de analyse van de functionele beveiliging van dit document.

Nummer

Titel

O1

Inloggen in het systeem

O2

Uitloggen uit het systeem

O3

Aanmaken van een gebruiker

O5

Verwijderen van een gebruiker

O6

Activeren van een gebruiker

O7

Deactiveren van een gebruiker

O8

Aanpassen van de toegangsrechten van een gebruiker

O9

Aanpassen van de toegangsrechten van een gebruikersgroep

O10

Aanmaken van een gebruikersgroep

O11

Aanpassen van een gebruikersgroep

O12

Verwijderen van een gebruikersgroep

O13

Zoeken van een gebruiker

O14

Zoeken van een gebruikersgroep

I1

Identificatie via CTI/IVR

I6

Authentificatie via CTI/IVR

I2

Identificatie van gestructureerde email

I3

Authentificatie van gestructureerde email

I7

Identificatie op het portaal

I8

Authentificatie op het portaal

I16

Manuele identificatie

I17

Bepalen of authentificatie nodig is

I18

Manuele authentificatie

3

#,&#

6((#

&5%

Identity management (IdM) : Identity management (ID management) is een beheersysteem dat toelaat om de individuen te identificeren en om hun toegang tot informaticamiddelen binnen een organisatie op een centrale manier te controleren door de identiteiten te koppelen aan toegangsrechten. LDAP (Lightweight Directory Access Protocol) is een protocol dat toelaat om directories te creëren en te beheren. LDAP definieert : • Een netwerkprotocol om toegang te krijgen tot informatie opgeslagen in de directory • Een informatiemodel dat de vorm en het type informatie definieert • Een « name space » die definieert hoe de informatie wordt georganiseerd en hoe ernaar wordt verwezen • Een distributiemodel voor het verspreiden van de gegevens • Een uitbreidbaar protocol en datamodel. OCR (optical character recognition) software voor de optische herkenning van karakters wat toelaat om een afgedrukte tekst te recupereren in een bewerkbaar bestand. PIN (personal identification number). PINs worden in het algemeen toegekend aan bankkaarten voor het gebruik van de bankautomaten. In het kader van het federaal digitaal identiteitskaart project zal een PIN geassocieerd worden met de digitale identiteitskaart om de houder van de kaart te authentificeren. Plug-in : een derden software module die zich in een softwarepakket integreert om nieuwe functies ter beschikking te stellen. Plug-ins worden meestal niet ontworpen om op zichzelf te functioneren maar dienen specifiek om geïntegreerd te worden in bestaande toepassingen. SAML (Security Assertion Markup Language) een uit XML (eXtensible Markup Language) ontstane standaard die een gebruiker toelaat om zich voor verschillende met elkaar geassocieerde websites slechts één keer te verbinden XML (eXtensible Markup Language of “uitbreidbare beschrijvingstaal”) is een standaard van het World Wide Web Consortium en is een speciale “metataal“ die de vorm van de informatie definieert en beschrijft. Het gaat dus min of meer over een beschrijving van de structuur en het formaat van een gegevensbestand.

Vertrouwelijk

© FOD Financiën


FOD Financiën Programma Multi-kanaal Dienstverlening Security & Control V3.0

Recommend Documents