Column maart 2007

In deze column hebben we het al vaker over taakverdeling gehad. Security Incident Management wat de DMZ-details niet mag meenemen, of een applicatie-doelgroep die live gaan belangrijker vond dan vertragende securityfixes. Het moge misschien saai klinken, maar organisatie en een juiste taakverdeling ís gewoon uitermate relevant voor een juiste bescherming. En dan praten we niet over in ruimere zin relevante zaken zoals functiescheiding en interne controle, maar over een keten-zonder-zwakste-schakel en vermijding van kastjes-en-muren.

Een fraai voorbeeld hiervan vinden we in grotere Intranetten waar men langzaamaan overgaat op Service Oriented Architecture en web services. Dat heeft twee grote gevolgen:
· Het aantal servers dat met elkaar moet communiceren groeit explosief. Hadden we vroeger alleen applicatie-machine en een centraal midframe en/of databasecluster, nu kan een “applicatie” bestaan over services die over misschien 5 servers verdeeld zijn.
· De onderlinge communicatieprotocollen convergeren naar web services oftewel SOAP over http.
Dat tweede is een zegen, want iedere nieuw gekochte of gebouwde applicatie kan (behoudens wat dialect-problemen) met de anderen babbelen. Maar ook een vloek: de openheid staat jan en alleman met de eigen browser toe om met een paar simpele XML-statements diezelfde service aan te roepen! En ook is encryptie van het verkeer even wat lastiger dan bij propietary communicatie zoals Oracle SQL*Net, MS DCOM of IBM MQ.

Voor Internet-communicatie is het probleem goed te verhelpen omdat we daar een sleutelgat-model van buiten naar binnen kennen, de B2B-gateways oftewel ‘postkantoren’. En daar kunnen we extra security-standaards hanteren zoals WS-Security, waarbij elke service-aanroep even streng beveiligd wordt als een webpagina. Dus inclusief ‘logon’, applicatie-credentials of zelfs PKI.
Voor ons Intranet ligt e.e.a. een stuk lastiger. Zoneren met routers klinkt leuk, maar vaak heeft eenzelfde machine zowel webpagina’s te serveren als web services en de browser moet dus bij de eerste wél en de tweede níet kunnen. Op puur TCP/IP ACL (Access Control List) niveau komen we er dus meestal niet.
Er zijn, gelukkig, een aantal technieken te bedenken waarmee we er wél komen. Te denken valt aan
· ACL’s in de specifieke IP-interfaces van alle servers, waarin alleen andere servers ‘vertrouwd’ worden. Natuurlijk krijgt dan de webpagina-kant van de machine een ander interface dan de webservice-kant.
· ACL’s in de http-laag van de webservice-kant.
· Encryptie via SSL met tweezijdige certificaten, of met IPSec.

Bij zowel de ACL- als de encryptie-verhalen moeten we erg uitkijken qua beheerbaarheid; gezien de exponentieele last van het onderhouden van honderden n-op-m tunnels is centrale tooling haast onvermijdelijk, soms toegroeiend naar een komplete PKI-infrastructuur. Maar in de praktijk ligt de uitdaging minstens evenveel in taakverdeling. Want als we naar een typische organisatie kijken, dan konstateren we dat
a) De genoemde technieken op meerdere OSI-niveau’s liggen. IP-ACL zit op laag 4, http-ACL op laag 7, en de encryptie kent wederom de keuze (SSL op 7 en IPSec op 4)
b) Die niveau’s in al onze wijsheid aan verschillende beheer-afdelingen of zelfs outsource-partijen toebedeeld zijn!

Laag 4 hoort typisch bij de Networks groep thuis, inclusief toewijzing van IP adressen en ACL’s. Laag 7 zal de Server-groep zijn, of zelfs de applicatiegroep die voor het ijzer weer op anderen leunt. Maar écht leuke hoofdpijn krijgen we bij encryptie: of we nu op laag 4 of laag 7 versleutelen, web service loadbalancing kan daardoor fors gehinderd worden. Speciaal als de services sessie-gebonden zijn dus ‘affiniteit’ (via cookies) eisen, want dan moet de loadbalancer in de SOAP-header kunnen kijken zonder encryptie. Per set services moet er nu configuratiewerk gebeuren aan de loadbalancer (hardware of software); en die kan onder Networks vallen maar misschien ook nog wel onder wéér een andere groep.

We zien de bui dus al hangen: het ‘handelen in het belang van de opdrachtgever’ van ons vakgebied vereist dat we eerst uitknobbelen hoe die opdracht-lijnen het beste kunnen gaan lopen. En daarna pas komen de beveiligings-techneuten aan bod….

Veel organisatie- en securityplezier,

<Erik>