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.
In dit hoofdstuk worden de technische onderwerpen geschetst. Een overzicht van details per technisch component zijn terug te lezen in de CMDB (zie de 'Template CMDB inrichting', en TOPdesk, onder: TOPdesk / Inloggen als behandelaar / hamburger-TOPdesk-Menu / Modules / Nieuw Asset management / middelenoverzicht. Hierbij vul je in het volgende veld in: Middelen zoeken 'Mulesoft' of 'S003359').
De figuren in dit hoofdstuk volgen de richtlijnen van zonering van de Nederlandse Overheid Referentie Architectuur.

In dit hoofdstuk staan de volgende onderdelen beschreven:

Overzichtstekeningen Landschap IP

In onderstaande figuren staan de overzichtstekeningen van het Integratie Platform (IP) landschap voor IP3&4 (DC1.5 & DC1.0) en IP2 (DC1.5 & DC1.0). In deze overzichtstekeningen zijn de alle technologie ontwerpen per IP weergegeven.

IP3&4 DC1.5 & DC1.0

Figuur 5: Overzichtstekening Landschap IP3&4 DC1.5 & DC1.0
In Figuur 5: Overzichtstekening Landschap IP3&4 DC1.5 & DC1.0 staat weergegeven welke Solution building Blocks (SBB) in de derde versie van het Integratie Platform zijn opgenomen. De onderdelen die opgenomen zijn:

• verschillende zones (Internet, DMZ en Intern),
• technologieën (API platform, Message Queueing, Managed File Transfer),
• omgevingen (Acceptatie, Productie en Uitwijk),
• netwerkverbindingen (HTTPS, AMQP, SFTP, TCP),
• netwerkcomponenten (Netscaler, InfoBlox),
• en de bouwstraat (CI/CD).

Alle SBBs bevinden zich in DC1.5 Intern, DC1.5 DMZ of Internet, behalve voor RabbitMQ. RabbitMQ bevindt zich in zowel DC1.5 Intern voor Intern verkeer als DC1.0 voor extern verkeer via de DMZ in DC1.0. Dit is in lijn met de Ontwerp beslissingen.
Voor meer informatie over netwerkconfiguratie wordt verwezen naar de CMDB.

IP2 DC1.5 & DC1.0

Figuur 6: Overzichtstekening Landschap IP2 DC1.5 & DC1.0
In Figuur 6: Overzichtstekening Landschap IP2 DC1.5 staat weergegeven welke Solution building Blocks (SBB) in de tweede versie van het Integratie Platform zijn opgenomen. De onderdelen die opgenomen zijn:

• verschillende zones (Internet, DMZ en Intern),
• technologieën (API platform, Message Queueing, Managed File Transfer),
• omgevingen (Acceptatie, Productie en Uitwijk),
• netwerkverbindingen (HTTPS, AMQP, SFTP, TCP),
• netwerkcomponenten (Netscaler, InfoBlox),
• en de bouwstraat (CI/CD).

Alle SBBs bevinden zich in DC1.5 Intern, DC1.5 DMZ of Internet, behalve voor RabbitMQ. RabbitMQ bevindt zich in zowel DC1.5 Intern voor Intern verkeer als DC1.0 voor extern verkeer via de DMZ in DC1.0. Dit is in lijn met de Ontwerp beslissingen.
Voor meer informatie over netwerkconfiguratie wordt verwezen naar de CMDB.

Technologie ontwerp per omgeving

In dit hoofdstuk staan de vijf technologie ontwerpen van het Integratie Platform omschreven. Dit zijn:

• API Platform omgeving Mulesoft HA Cluster en Runtime Fabric,
• Message Queue omgeving RabbitMQ,
• Managed File Transfer omgeving sFTP,
• Automation Platform omgeving Ansible AP,
• En CI/CD bouwstraat Azure DevOps.

API Platform omgeving

In deze paragraaf worden de technische ontwerpen van de verschillende API Platform omgevingen weergegeven. Hierbij wordt onderscheid gemaakt tussen datacenter locaties en soorten platformen. Op dit moment wordt gebruik gemaakt van Datacenter 1.0 en Datacenter 1.5. Daarnaast wordt gebruik gemaakt van Mulesoft High Available Clusters (HAC) en Mulesoft Runtime Fabric (RTF).

Security excepties

Voor een juiste werking van de API platformen moet de interne zone ontsloten worden naar de Mulesoft Control plane op het internet, middels HTTPS 443 en TLS 5044 point-to-point via specifieke URLs. Hierbij worden klaargezette configuratie gegevens opgehaald uit de Mulesoft Control Plane. Er worden geen gegevens 'gepusht' naar de interne on-premises omgeving.
Daarnaast moet SELinux op 'permissive' modus worden gezet voor een juiste werking van de API platformen.
Aangezien deze twee situaties ('data-pull' en 'SELinux') afwijken van de security richtlijnen van Rijkswaterstaat, zijn hiervoor security excepties aangevraagd en verkregen. Voor meer informatie over security excepties, zie de sharepoint van TP-ESB/ Beheerteam IVP/ Infrastructuur/ Excepties.

Technology Model HAC DC1.5

Figuur 7: Technologie model voor Mulesoft HAC DC1.5
Het voorgaande figuur beschrijft de belangrijkste technologie componenten waaruit de oplossing is opgebouwd.
Vanwege de MKS-eis bestaat het LMW2 HAC platform uit twee delen; productie is dubbel uitgevoerd, zowel in AM2 als AM4 een identieke configuratie qua hardware. Op AM2 worden de resources verdeeld tussen P, A en T (zie ook BE-IP (ESB)-05).
Regulier verkeer verloopt via de Netscaler. LMW2-specifiek verkeer verloopt via een InfoBlox DNS service die door LMW beheerd wordt zoals beschreven in hoofdstuk 3.9 LMW specifiek. API's worden uitgerold via de bouwstraat zoals beschreven in Bouwstraat (CI/CD). Flex Gateway is als concept ingetekend en nog niet operationeel.

Technology Model RTF DC1.5

Figuur 8: Technologie model voor Mulesoft RTF DC1.5
Het voorgaande figuur beschrijft de belangrijkste technologie componenten waaruit de oplossing is opgebouwd. Verkeer verloopt via de Netscaler. API's worden uitgerold via de bouwstraat zoals beschreven in Bouwstraat (CI/CD). Flex Gateway is als concept ingetekend en nog niet operationeel.

Message Queue omgeving

Technology Model MQ DC1.5 & DC1.0

Figuur 9: Technologie model voor RabbitMQ dienstverlening in DC1.5 (Intern) & DC1.0 (DMZ)
Bovenstaand figuur beschrijft de belangrijkste technologie componenten waaruit de oplossing is opgebouwd voor de interne TestAcceptatieProductie in DC1.5 en de DMZ TestAcceptatie en Productie in DC1.0. Hierbij wordt gebruik gemaakt van RabbitMQ.
RabbitMQ wordt voor het interne verkeer als dienst afgenomen bij het Cloud Native Applicatie Platform (CNAP). Een overzicht van details voor RabbitMQ zijn terug te lezen in de CMDB (zie de 'Template CMDB inrichting' en TOPdesk, onder: TOPdesk / Inloggen als behandelaar / hamburger-TOPdesk-Menu / Modules / Nieuw Asset management / middelenoverzicht. Hierbij vul je in het volgende veld in: Middelen zoeken 'IV Supporting IV Service' of 'S005010').

Security exceptie

Voor verkeer van en naar het internet toe zijn VMs met RabbitMQ ingericht in de DMZ:NWR omgeving van DC1.0. Enkel in DC1.0 bestaat een volwaardige DMZ zone, waarmee het Integratie Platform kan voldoen aan het zoneringsbeleid van RWS. Op deze manier kunnen klanten op veilige wijze van en naar buiten de RWS organisatie berichten uitwisselen.
Aangezien deze situatie afwijkt van de security architectuur richtlijnen van Rijkswaterstaat, is hiervoor een security exceptie aangevraagd en verkregen. Voor meer informatie over security excepties, zie de sharepoint van TP-ESB/ Beheerteam IVP/ Infrastructuur/ Excepties.

Managed File Transfer omgeving

Vanuit beheer en performance perspectief blijft MFT los van RTF. Mogelijk verandert dit nog in de toekomst, ofwel wordt er een geschikte derde dedicated partij/dienstverlener voor gevonden. Voor nu wordt in Datacenter 1.5 deze oplossing één op één overgenomen.
Het gedetailleerde ontwerp van managed file transfer (DLD MFT) is te vinden op Confluence: https://rws-confluence.prepend.net/spaces/INFRAARCH/pages/189136968/DLD+MFTBlocked active content: img. Hier staan de verbindingen met de Mule MFT API vernoemd, rol van Netscaler en zijn de onderstaande vier MFT scenario's uitgewerkt.
Er zijn vier scenario's mogelijk voor verplaatsen van bestanden, te weten:

• Van externe klant naar interne afdeling middels het pushen van bestanden, dat wil zeggen vanaf extern naar intern;
• Van externe klant naar interne afdeling middels het ophalen van bestanden, dat wil zeggen vanaf extern naar intern;
• Van interne afdeling naar externe klant middels het pushen van bestanden, dat wil zeggen vanaf intern naar extern;
• Van interne afdeling naar externe klant middels het ophalen van bestanden, dat wil zeggen vanaf intern naar extern.

Pushen
Pushen van bestanden werkt geautomatiseerd, waarbij bestanden die binnenkomen op de FTP server, automatisch doorgestuurd worden naar de doel-FTP server. Hierbij zet klant bestand neer op de FTP server. In DLD MFT dit verder uitgewerkt.
Ophalen Ophalen van bestanden werkt middels polling of scheduling. Een applicatie checkt op een vooraf bepaalde frequentie (per seconde, minuut, uur, eens per dag) in hoeverre een bestand klaar staat om opgehaald te worden en op de toegewezen bestandslocatie neergezet moet worden. In DLD MFT is dit verder uitgewerkt.
Overigens werken alle varianten met een polling-variant.

FTP servers in DMZ
Van externe klant naar interne afdeling wordt gebruik gemaakt van de FTP servers in DMZ. Van interne afdeling naar externe klant wordt bestand rechtstreeks van de interne FTP server verstuurd naar de externe klant.

Technology Model MFT DC1.5

Figuur 10: Technologie model voor MFT DC1.5
Het voorgaande figuur beschrijft de belangrijkste technologie componenten waaruit de oplossing is opgebouwd voor DC1.5. Deze componenten bestaan uit het datacenter waarin een component zich bevindt, evenals de onderlinge verbondenheid tussen de verschillende componenten. Alle componenten zijn redundant uitgevoerd.

Security exceptie

Verkeer verloopt via TCP poort 22 (SFTP protocol) over de Netscaler en diens Reverse Proxy functionaliteit. Aangezien deze situatie afwijkt van de security richtlijnen van Rijkswaterstaat, is hiervoor een security exceptie aangevraagd en verkregen. Voor meer informatie over security excepties, zie de sharepoint van TP-ESB/ Beheerteam IVP/ Infrastructuur/ Excepties.

Automation Platform omgeving

Configuratie beheer wordt uitgevoerd via Ansible van Red Hat. Hiervoor wordt gebruik gemaakt van Ansible Automation Platform van IRI-Linux.
Red Hat Ansible Automation Platform is een end-to-end automation platform waarmee systemen geconfigureerd kunnen worden, software gedeployed kan worden, en geavanceerde workflows aangemaakt kunnen worden. Dit gebeurd middels playbooks.
Playbooks worden opgeslagen in de on-premises GitLab omgeving van Rijkswaterstaat. Dit wijkt af van de code repository van de bouwstraat, welke afgenomen wordt bij Microsoft Azure (zie Bouwstraat (CI/CD)). Dit hoofdstuk zal verder worden uitgebreid zodra configuratiebeheer verder vorm krijgt. 

Figuur 11: Overzicht voor configuratie beheer

Bouwstraat (CI/CD)

De bouwstraat (2.0) is ontwikkeld in samenwerking met OSR en voorziet in een geautomatiseerde wijze van deployen van applicaties naar de Acceptatie en Productie omgeving.
Om de applicatie (API) te kunnen deployen naar de productie omgeving moet de ontwikkelaar/ aanleverende partij goedkeuring verleend krijgen. Voor een snelle doorloop van ontwikkeling tot acceptatie is het deployment proces voor de OTA omgeving geheel geautomatiseerd.

Proces van API deployment

Figuur 12: Technologie model voor de bouwstraat
In Figuur 12 wordt het proces van API- en applicatie-broncode tot deployment op de runtimes beschreven. Hieronder volgt een toelichting.

1. Broncode van een applicatie of API wordt geplaatst door ontwikkelaars/ aanleverende partij in de RWS Azure Code Repository;
2. Geautomatiseerde deployment verloopt middels Azure Pipelines in Azure DevOps;
3. Via Azure Pipelines wordt de broncode opgehaald uit de code repositories,
4. gepackaget in Azure Artifacts (en als package opgeslagen),
5. gedeployed naar de Anypoint Platform Control Plane,
6. en vervolgens opgehaald door de Runtime servers, waar de applicatie package uitgerold wordt in de desbetreffende omgeving (Test, Acceptatie, Productie of Uitwijk).

Via de Control Plane kan de status gecheckt worden van de gedeployde applicatie.

Netwerk

In onderstaand figuur staat een algemeen Technisch Model van het Integratie Platform (IP) landschap voor alle oplossingen met poorten en protocollen.

Figuur 13: Algemeen Technisch Model IP poorten en protocollen

Load balancers

Het integratie platform maakt gebruik van loadbalancers. Voor OTA en Prod in DC1.5 wordt gebruik gemaakt van één Netscaler, de scheiding tussen OTA en Prod kan in de netscaler zelf gemaakt worden. De loadbalancing vindt plaats op basis van het netwerkverkeer en maakt gebruik van routeID. Het gebruikte protocol is HTTPS (met poort 443). Voor sFTP (poort 22) wordt gebruik gemaakt van reverse proxy.
FTPS (poort 21) wordt alleen toegestaan voor P-Direct. JMS (poort 61616 en 61617) wordt niet toegestaan.
Gezien de bestaande MFT dienstverlening en ActiveMQ dienstverlening, blijven de oude loadbalancers in DC1.0 (want noodzakelijk voor bestaande APOP installatie en MFT) bestaan in de vorm van HAProxy.
De loadbalancing tussen RTF Prod en RTF Prod Uitwijk wordt via de Infoblox DNS servers van LMW gereguleerd op basis van prioriteitstelling. Hierbij wordt verkeer verstuurd naar P1 op DNS niveau en doorgestuurd naar de RTF machines. Indien uitwijk nodig is, routeert LMW zelf het verkeer van P1 naar P2 en daarmee de achterliggende RTF machines.

Wide Area Networks

De actuele nodes bevinden zich binnen hetzelfde (productie) netwerk/Vlan. In DC 1.5 is het één VLAN per DC; in DC 1.0 zijn er meerdere VLAN's.

Firewalls

Door het zoneringsmodel en de inrichting van de netwerken van RWS wordt er gebruik gemaakt van de firewalls. In verschillende omgevingen (Datacenterconcepten) zijn hiervoor verschillende technologieën gebruikt. De benodigde verbindingen moeten aan de NORA zoneringseisen voldoen.
In het DC 1.0 concept draait de tooling voor CI/CD van het integratie platform op VM's in de KA-omgeving. Er wordt gebruik gemaakt van hardware firewalls. Hierin zijn de volgende verbindingen initieel nodig om de werking van het platform te garanderen:

• De verbinding tussen het DC 1.0 concept (waar CI/CD tools zich in de migratiefase blijven bevinden) met AnyPoint Platform in de cloud.

Deze situatie is tijdelijk, er wordt gemigreerd naar een hybride cloud gebaseerde nieuwe oplossing voor het DC 1.5 concept bij zowel IP2 als IP3.
In het DC 1.5 concept draait het integratie platform op VM's. De benodigde verbindingen:

• Verbinding tussen AnyPoint platform als management applicatie (in de cloud) en de runtimes (intern netwerk in DC1.5);
• De verbinding tussen de TAP omgevingen op het interne netwerk en internet (via forward webproxy);
• De verbinding tussen de productie omgeving op het interne netwerk en tools op het interne netwerk en in DMZ (om het verkeer van en naar internet veilig te laten verlopen);
• De verbinding tussen de DMZ en het internet (om het verkeer van en naar internet veilig te laten verlopen;
• De verbinding van de management omgeving met de TAP omgevingen;
• De verbinding van de productie omgeving met de acceptatie en test omgevingen;
• Verbinding van de NFS storage met alle runtimes die opslagruimte nodig hebben.

Autorisatie en Authenticatie

Autorisatie en authenticatie gebeurt tegen de RWS IAM bouwsteen. Dit gebeurt via ADFS met het SAML protocol (ADFS voor interne gebruikers en andere rijks overheden en OpenAm voor externe gebruikers-derden). Toegang wordt gecontroleerd via de Access Management Reverse proxy server of zoals is aangegeven in Toegang derden. Er wordt initieel aangesloten op de ADFS voor interne gebruikers en API management. Wanneer de RWS IAM bouwsteen verder is ontwikkeld en er een enkel koppelvlak is voor zowel ADFS als OpenAm komt ook eHerkenning beschikbaar binnen het integratie platform.
Voor platform componenten die in de cloud zijn gepositioneerd, wordt gebruik gemaakt van Azure AD in vergelijkbare werking als lokaal gebeurt.
Bij TLS authenticatie wordt de functioneel beheer van gebruikers (en certificaten) door de klant gedaan. Het technisch beheer wordt door het TPB ESB team uitgevoerd.
Servers op zowel het interne als het DMZ netwerk worden voor beheer benaderd via Citrix en daarop vervolgens MobaXterm. Zodra Keycloak BIO complaint is, wordt het Integratie Platform hiermee gekoppeld.

Figuur 14: Overzicht IAM IP (ESB) Platform

Monitoring

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

Figuur 15: Overzicht monitoring IP (ESB) 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 platform volgens de BIO normen in te richten worden de applicatie logs volgens de SIEM (Splunk) aansluitwaarden opgeleverd.

IV Infra

Het platform wordt op IV Infra gemanagede server bouwstenen geïnstalleerd of als Infra Virtual Appliance (IVA). De managed server bouwstenen wordt door IV Infra tot aan het OS of Database beheerd en gemonitord, voor de IVA wordt een VM ter beschikking gesteld.
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 Splunk gebruikt.

IV Platform Technisch Beheer

Voor applicatie monitoring is CheckMK het standaard product en wordt op dit moment voor Infra-applicatie specifieke zaken, zoals beschikbaarheid, hiervoor 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. Om meer proactief en kwaliteit gericht te werken is een applicatie specifieke monitor tool nodig, voor het Integratie platform wordt dit geleverd door de management bouwsteen Anypoint. Het totale doel van de API monitoring is om de performance, beschikbaarheid, kwaliteit en het gebruik van de omgeving inzichtelijk te maken en proactief te beheren. Vanwege de AVG gevoelige informatie over gebruik moet deze dienst intern worden gehost.
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)
• Tool: Splunk
  • Beschikbaarheid per API
  • Hoeveelheid gebruik per API
  • Locatie gebruik per API
  • Baseline kwaliteit services tbv advisering afnemer
  • Flow tussen de servers

Platform afnemer

Voor de afnemers van de platform bouwstenen wordt dezelfde dashboard tool, CheckMK, gebruikt maar dan met de gegevens over de afgenomen dienst. Hiervoor worden aparte groepen aangemaakt om alleen die gegevens die interessant zijn als afnemer beschikbaar te maken. Vanwege de AVG gevoelige informatie over gebruik moet deze dienst intern worden gehost.De volgende metrics worden op de dashboard weergegeven:

• Beschikbaarheid per API
• Hoeveelheid gebruik per API
• Locatie gebruik per API

De informatie vanuit Splunk is voor de klanten op dit moment niet beschikbaar. Dat komt door het feit dat de toegang verlenen betekent alle informatie kunnen inzien, ook die van andere klanten.
Er wordt eraan gedacht om de indexering in de logging toe te voegen, waardoor de splitsing van informatie en toegang mogelijk wordt. Dit vergt aanpassing van alle huidige logging.

Management rapportage

Voor de up-time monitoring van het platform (in het kader van SLA) wordt er ook gebruik gemaakt van Prometheus. De visualisatie van beschikbaarheid/bereikbaarheid/up-time voor URL wordt in SAS en in Grafana beschikbaar gesteld.