6. Technology layer

Het fysieke ontwerp beschrijft de fysiek technische aspecten van de oplossing. Het geeft weer hoe de logische componenten, beschreven in het logisch ontwerp technisch opgezet zijn en/of geplaatst worden op fysieke componenten/bouwstenen/nodes in de infrastructuur.

Functioneel ontwerp per omgeving

In dit hoofdstuk wordt op basis van het functioneel model beschreven uit welke componenten (Technical Nodes) het platform is opgebouwd.
Binnen het platform zijn de volgende Technische Nodes gedefinieerd:

De uitwerking van de technische nodes is geen onderdeel van het HLD en wordt uitgewerkt in de betreffende Detail Level Designs (DLD's).

Functioneel Model – Productie

Figuur 5-1 geeft een overzicht van de belangrijkste technologie componenten waaruit het platform is opgebouwd.

Figuur 5 1: Functioneel model - Productie

Functioneel Model – Acceptatie

Figuur 5-2 beschrijft de belangrijkste technologie componenten waaruit de oplossing is opgebouwd.

Figuur 5 2: Functioneel model - Acceptatie

Functioneel Model – Test

Figuur 5-3 beschrijft de belangrijkste technologie componenten waaruit de oplossing is opgebouwd.

Figuur 5 3: Functioneel model - Test

Functioneel Model – Ontwikkel

Figuur 5-4 beschrijft de belangrijkste technologie componenten waaruit de oplossing is opgebouwd.

Figuur 5 4: Functioneel model - Ontwikkel

Netwerk

Load balancers

De benodigde functionaliteit m.b.t. de Firewalls kan worden gerealiseerd o.b.v. de standaard beschikbare bouwblokken.

Wide Area Networks

De benodigde functionaliteit m.b.t. de Wide Area Networking kan worden gerealiseerd o.b.v. de standaard beschikbare bouwblokken.

Firewalls

De benodigde functionaliteit m.b.t. de Firewalls kan worden gerealiseerd o.b.v. de standaard beschikbare bouwblokken.

Uniform Resource Locator (URL) Oplossings richting nog definieren/uitwerken

Via het IVP-GIS platform wordt op basis van URL's Geo functionaliteit ontsloten richting gebruikers. De basis voor een LCM traject is het realiseren van de (nieuwe) functionaliteit op een nieuwe/separate infrastructuur stack. Dit betekent dat de nieuwe functionaliteit (tijdelijk) naast de huidige beschikbaar wordt gemaakt. URL's zijn eenduidig en het is dus niet mogelijk om (eenvoudig) onderscheid te maken tussen de huidige- en de nieuwe applicatie(s).

URL principes:

1. URL persistentie; nieuwe URL's voor 10 jaar garanderen.
2. Onderscheid tussen publieke en interne URL's; Publieke URL's blijven gelijk (I) c.q. – Dit om te voorkomen dat externe gebruikers worden geconfronteerd met 'broken links'. Interne URL's zoveel mogelijk behouden. Interne URL's zijn veelal complex van aard waardoor persistentie moeilijker is te realiseren.

LCM migratie strategie:

1. Nieuwe URL's gebruiken voor het nieuwe GIS platform; Nieuwe URL's geven de mogelijkheid om gefaseerd te migreren naar de nieuwe omgeving.
2. Huidige URL's over nemen naar het nieuwe platform; URL's migreren heeft tot gevolg dat er in één keer (big bang) moet worden gemigreerd.
3. Combinatie op basis van URL principes I en II;

@TODO: afspraak is dat er een plaatje komt met de methode die we gaan gebruiken.

URL naamgeving

Om alle GEO diensten op een juiste manier te ontsluiten moeten de URL's waar ze via ontsloten worden een goede naamgeving krijgen.
Naamgeving URL = [omgeving-]<doel>[.intranet].rijkswaterstaat.nl/<versie of sub doel>:
<doel>, we kennen de volgende overkoepelende doelen :

• maps – GeoWeb en PDOK en portal en Geonetwork
• geo - GeoServer en ArcGIS Server services en algemene geo zaken
• etl – FME Server

[omgeving-], de URL kan voor verschillende omgevingen ingezet worden en we maken onderscheid door onderstaande toe te voegen aan het doel:

• Productie, geen toevoeging aan doel
• Acceptatie omgeving, 'acc-' toevoegen aan doel. Bv acc-geo
• Test omgeving, 'tst-' toevoegen aan doel. Bv tst-geo
• Ontwikkel omgeving, 'ont-' toevoegen aan doel. Bv ont-geo

[.intranet], om onderscheid tussen intern en extern verkeer (naar internet) wordt er bij alleen intern gebruik een extra domein 'intranet' tussen het <doel> en 'rijkswaterstaat.nl' geplaatst.
<versie of sub doel>, achter de DNS naam worden aparte sites geconfigureerd om een sub doel met of zonder software versie aan te geven.
De gebruikte GIS URL's staan verder uitgewerkt in onderstaande tabel.

Authenticatie en autorisatie

Een aandachtpunt binnen ons platform is de manier waarop de authenticatie is ingeregeld. De gebruikers verwachten een Single Sign-On experience.
Single Sign-On (SSO) is een authenticatiemodule waarmee je – door ingelogd te zijn in je organisatie account – in één keer toegang krijgt tot meerdere applicaties. Met slechts één gebruikersnaam en één wachtwoord. SSO zorgt ervoor dat je geen tientallen inloggegevens hoeft te onthouden of eindeloos wachtwoorden hoeft te resetten. Dit maakt werken een stuk efficiënter en bovendien véél veiliger. Het voorkomt ook dat je te simpele wachtwoorden gebruikt voor extra applicaties.
Authenticatie en autorisatie gebeurt tegen de RWS Active Directory. De secure zone heeft geen Active Directory maar een SAML oplossing (ADFS voor interne gebruikers en OpenAm voor externe gebruikers-derden). Toegang wordt gecontroleerd via de Access Management Reverse proxy server of zoals is aangegeven in Toegang derden.

Authenticatie

Authenticatie word ingeregeld met het ADFS protocol gebruikers aan te melden via de RWS IAM Broker

Autorisatie

In het huidige landschap is de IAM administratie op twee manieren, een centrale- en een decentrale-manier geïmplementeerd. De decentrale implementatie verhoogt de beheers last en binnen het team aangezien er hier een proces voor ingeregeld dient te worden.
Binnen de huidige applicatie architectuur van de leverancier(s) ligt de focus op federated IAM administratie/ontsluiting. Hierdoor komt op termijn de non-federated functionaliteit te vervallen wat een gedwongen migratie tot gevolg heeft.
Zoals is opgenomen in Ontwerp besluit OB-GIS-005; ondersteund het IVP-GIS platform nog beide opties.

Release deployments

Deployment voor de applicaties binnen de verschillende IVP-GIS SBB's wordt gedaan op basis van

Monitoring

In onderstaande overzicht wordt het monitor landschap bij Rijkswaterstaat weer gegeven zoals toegepast bij de afdeling CIV. In het overzicht staan 4 actor disciplines met elk een eigen dashboard die vanuit drie verschillende inventarisaties, security – Infra – applicatie, worden gevoed. In dit hoofdstuk wordt het doel van elk type monitoring beschreven .
Figuur 5 5: Overzicht monitoring GIS Platform

Security

Binnen het Security Information & Event Management(SIEM) platform (ten behoeve van het Security Operations Centre (SOC)) wordt alle log data vanuit alle domeinen en assets binnen Rijkswaterstaat verwerkt en beschikbaar gesteld voor de security analisten van het SOC. De security analisten zijn dan in staat om de systemen te monitoren op cyberincidenten/-aanvallen en daarbij het bijbehorende proces te beveiligen.
Om het GIS platform volgens de BIO normen in te richten worden de applicatie logs volgens de SIEM (splunk) aansluitwaarden opgeleverd.

IV Infra

Het GIS platform wordt deels op IV Infra gemanagede server bouwstenen geïnstalleerd. Deze server bouwstenen wordt door IV Infra tot aan het OS of Database beheerd en gemonitord.
Basis monitoring bestaat uit het CPU-, Geheugen-, Schijfruimtegebruik op basis van thresholds naast een check of de server en database in de lucht zijn. Op het moment van schrijven wordt zowel splunk als nagius gebruikt.

IV Platform Technisch Beheer

Voor applicatie monitoring is er geen standaard product en wordt op dit moment voor Infra-applicatie specifieke zaken zoals beschikbaarheid CheckMK gebruikt. CheckMK geeft de mogelijkheid aan de "buitenkant" van de applicatie te kijken en monitort of de applicatie buiten de opgegeven tresholds loopt. Dit is waardevolle informatie voor beheer maar geeft nog niet aan waarom dit gebeurt en of er verbeteringen van de omgeving mogelijk zijn.
De volgende metrics worden verzameld en op de dashboard (CheckMK) weergegeven:

• Tool: CheckMK
  • CPU gebruik
  • Mem gebruik
  • Disk gebruik (en ook specifiek folder gebruik zoals Temp)
  • Webserver gebruik (zoals IIS application pools)

Platform afnemer

Voor de afnemers van de platform bouwstenen wordt, op basis van de informatiebehoefte, een interface geïmplementeerd. De interface 'publiceert' de gewenste informatie zodat die kan worden opgenomen in het TAB dashboard van de afnemer. Hiermee wordt voorkomen dat we 'externe' partijen toegang moeten verlenen tot ons platform. Ook speelt dit beter in op de verschillende wensen van de afnemers en ons platform wat de informatiebehoefte is.
Vanuit het platform kunnen bv onderstaande metrics beschikbaar worden gesteld:

• Beschikbaarheid per webservice
• Hoeveelheid gebruik per webservice
• Locatie gebruik per webservice