Technology layer MQ

In dit hoofdstuk staat beschreven:

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.
Het fysieke ontwerp wordt uitvoerig weergegeven in de Visio HLD (V-HLD) van MQ. In dit document worden de technische onderwerpen geschetst.

Technologie ontwerp MQ

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.

Netwerk

In onderstaand figuur staat een algemeen Technisch Model van het Message Queueing (MQ) landschap voor alle oplossingen met poorten en protocollen.

Figuur 4: Algemeen Technisch Model MQ poorten en protocollen

Figuur 5: Gedetailleerde overzichtstekening MQ

Buiten naar binnen

Externe afnemer komt via mq.esb.rijkswaterstaat.nl vanaf het Internet over TCP/AMQPS met SSL:443 binnen op de DNS service InfoBlox, wordt doorgestuurd naar de HAProxy (Loadbalancer) en wordt round robin geloadbalancet naar 10.95.254.206/24 of 10.95.254.207/24 of 10.95.254.214/24 over default poort 5671.

DC1.5Intern naar DC1.0DMZ

Mulesoft haalt bericht op van Queues van klanten zet deze berichten door naar mq.esb.rijkswaterstaat.nl via HAProxy (Loadbalancer) en wordt round robin geloadbalancet naar 10.95.254.206/24 of 10.95.254.207/24 of 10.95.254.214/24 over default poort 5671

Protocollen en poorten

Oplossing maakt hoofdzakelijk gebruik van HTTPS verkeer over 443 en TCP:AMQP 5671/5672. Connectie met het AD verloopt via een LDAP koppeling.

Load balancers

Message Queueing 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. De oude loadbalancers in DC1.0 blijven in gebruik in de vorm van HAProxy.

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.

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.Toeschrijven naar MQ

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 MQ team uitgevoerd.

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 14: Overzicht monitoring MQ 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 van de tool op VMs in DMZ (DC1.0) 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.
Voor applicatie monitoring van de tool op CNAP in Intern (DC1.5) is Grafana via Prometheus het standaard product voor Infra -applicatie specifieke zaken, zoals beschikbaarheid. Hiermee kan meer proactief en kwaliteit gericht gewerkt worden, voor het beheer wordt dit geleverd door de management portaal van de applicatie. Het totale doel van de applicatie 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.

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 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 Grafana beschikbaar gesteld.