Patroon voor portaal toegangserver
- Onderdeel van
- Thema's
- Contact
- Guus van den Berg
- Guus.vandenberg@cip-overheid.nl
- Status
- Dit thema wordt momenteel opnieuw bekeken door de Expertgroep Beveiliging
Criteria
Integriteit, vertrouwelijkheid
Context
Een portaal of portal is een webapplicatie, die eindgebruikers via internet of bedrijfsnetwerken toegang geeft tot zowel toepassingen als gegevens. Er zijn grote organisaties die hun gehele IT-omgeving voor medewerkers ontsluiten via een portaal op het internet! Interne netwerken (LAN) zijn dan ‘verleden tijd’. Hieronder een voorbeeld van een klant en medewerker die informatie zoeken op een bedrijfsportaal.
Een portaal kan afhankelijk van de toepassing informatie ophalen vanuit verscheidene bronnen. Het portaal kan daarbij de gegevens samenstellen, veredelen (aggregeren) en ze op hetzelfde moment presenteren aan klanten, partners of medewerkers van een organisatie. Een portaal kan informatie uit verschillende databases en applicaties voor een gebruiker toegankelijk maken via vooraf gedefinieerde portlets; die in combinatie met elkaar het ‘portaal’ vormen, afhankelijk van de behoefte en bevoegdheden van de gebruiker. Behalve zoekfuncties bieden portalen toegang tot e-mail, nieuws en prijsinformatie en ontspanning. Voor organisaties bieden portalen een goede mogelijkheid om klanten een consistente ‘look and feel’ te geven voor de toegang tot applicaties, die voorheen ieder hun eigen toegangsprocedures en ‘gezicht’ hadden naar eindgebruikers. Een graag geziene functionaliteit van portalen is dat keuzemogelijkheden worden beperkt tot uitsluitend datgene waarvoor gebruikers bevoegd zijn en dat men daarvoor maar één keer hoeft aan te loggen; het z.g. Single Sign-On (zie hiervoor verder het patroon voor single sign-on).
Probleem
- Gevoelig voor inbreuk. Voor de klant of eindgebruiker fungeert een bedrijfsportaal als de ‘voorkant’ van de informatieketen, al dan niet toegankelijk via het internet. Hoewel portalen publiek vrij toegankelijke informatie kunnen verschaffen, zal gevoelige informatie pas verstrekt worden na authenticatie van de gebruiker. Probleem daarbij is dat Internet netwerk- en berichtenverkeer door de georganiseerde misdaad gemakkelijk op afstand kan worden ingezien, worden gekopieerd of gewijzigd.
- Concessies op beveiliging voor laagdrempeligheid. Een belangrijke eis voor een portaal is een laagdrempelige gebruikersinterface, maar vanwege die eis worden er vaak concessies gedaan op beveiligingsmaatregelen, waardoor het portaal in de keten een evident kwetsbare schakel vormt voor misbruik en digitale sabotage.
- Beperking J2EE Platform beveiliging. J2EE is ontworpen voor administratieve systemen en kan niet in alle gevallen voorkomen dat malicious portlet code het portaal beschadigt of dat gevoelige data ongeautoriseerd kan worden gelezen via een call vanuit andere interne portlets.
Oplossing
De set van benodigde maatregelen voor beveiliging van portalen is samengevat afhankelijk van:
- Toegangsketen: wordt toegang verleend vanuit een intern netwerk, een vertrouwd of semi-vertrouwd intranet of vanuit een niet vertrouwd netwerk zoals het internet.
- De aard van acties die gebruikers van het portaal (klant, partner of medewerker) moeten kunnen doen. Betreft de actie bepaalde publieke informatie raadplegen, vertrouwelijke informatie raadplegen of moeten gebruikers ook transacties kunnen uitvoeren?
- Portaal architectuur. Leveranciersafhankelijke architectuurkeuzes voor de mechanismen van toegang en autorisatieservices. In dit patroon beperken we ons tot generieke oplossingen.
Intern netwerk
De eenvoudigste portaalconfiguratie is toegang vanuit een beveiligd intern netwerk (LAN). Een voorwaarde hierbij is dat er geen aanvallen te verwachten zijn vanuit dit netwerk. Zowel het portaal als de clientomgeving en de gebruikersgegevens worden beschermd door de firewall KV (Koppelvlak). De clients kunnen direct met het Portalserver communiceren, omdat ze zich in hetzelfde beschermde netwerk bevinden. In dit voorbeeld is de Applicatieserver code en de Portalserver code op dezelfde fysieke machine geïnstalleerd. Alle gebruikersgegevens, zoals autorisaties zijn opgeslagen in de LDAP directory. De netwerkverbinding wordt beveiligd met behulp van TLS-encryptie, waarbij de client zich eenzijdig authenticeert aan de Webserver.
Intranet
Wordt toegang wordt verleend tot een portaal via een semi-vertrouwd extern netwerk, dan wordt de Client, Webserver en Portalserver met firewalls gescheiden van elkaar en van de Webserver. Er worden twee TLS verbindingen opgezet voor beveiliging van de communicatie, die de firewalls 1:1 doorlaten.
Internet
Wanneer toegang tot het portaal wordt verleend vanuit niet vertrouwde netwerken zoals het internet, dan wordt een afzonderlijke authenticatie component toegepast waarmee de gebruiker zich authenticeert. Vervolgens wordt toegang verleend naar de Web/portalserver. Hiervoor wordt een Authenticatie proxy gebruikt, ook wel Reverse proxy genoemd. De LDAP directory verstrekt gebruikersgegevens aan de proxy, de Web/Portal server en de andere systemen in de Front- en BackOffice. Load balancers worden gebruikt voor het verdelen van de gegevensstromen over de verschillende systemen.
Per functieblok is in onderstaande tabel aangegeven welke IB-functies werkzaam zijn in bovenstaande portal ketens. De koppelvlakken zijn standaard koppelvlakken, zoals beschreven in aangegeven patronen. Dat geldt ook voor de LDAP directory en het clientproces.
| Functieblok | Continuiteit | Zonering | Identificatie Authenticatie | Autorisatie | Vastleggen gebeurtenissen | Controleren Alarmering | Systeemintegriteit |
|---|---|---|---|---|---|---|---|
| Client proces | nvt | Beginpunt SSL tunnel | Username/ww 2-factor (extern) | nvt | nvt | nvt | Handhaven van beveiligingsfuncties |
| zie verder beschouwingsmodel:Client | |||||||
| Koppelvlak 1 | Intern-portaal via LAN: zie Patroon voor interne koppelvlakken voor de productieomgeving; koppelvlak 2 en 9. Extern-portaal via intranet: zie beschouwingsmodel Kanaal Vertrouwd koppelvlak V. Extern-portaal via Internet: zie beschouwingsmodel Kanaal Niet vertrouwd koppelvlak Ou en Oi. | ||||||
| Load balancer | Dubbele units Dubbele PSU |
nvt | nvt | nvt | Vollopen queue IB-events |
Drempelwaarde systeem-resources | Hardening Syst.patches |
| Authent. proxy | Dubbele units | Ongebruikte poorten uitgeschakeld of verwijderd | Pincode opstart Systeem ww |
Systeem-autorisaties | Syslog IB-events |
Drempelwaarde systeem-resources | Hardening Code scan/hash OS-patches Vulnerabilityscan |
| Koppelvlak 2 | zie Patroon voor interne koppelvlakken voor de productieomgeving; koppelvlak 2, 6 en 9 | ||||||
| Web-/Portalserver | Dubbele units Dubbele PSU |
Sandboxing | WW gescheiden van toepassing gegevens opgeslagen | temp-bestanden alleen voor systeembeheer toegankelijk | Bewaartermijn Vollopen media rollback |
vollopen queues en media | Foutloos berichtenverkeer en opslag RAID |
| LDAP directory | zie patronen: Themapatroon identity & access management en Patroon voor access management | ||||||
In onderstaande figuur zijn drie generieke portalconfiguraties afgebeeld in de context van één bedrijfsnetwerk. Afhankelijk van het aantal externe gebruikers kan een extra loadbalancer worden ingezet om de verkeersbelasting over de verschillende authenticatieproxies of webservers in de DMZ te kunnen verdelen.
Toegang tot gevoelige gegevens
Autorisatie is gebaseerd op authenticatie. Om zeker te zijn dat uitsluitend geautoriseerde gebruikers toegang verleend wordt tot het portaal, moet worden vastgesteld wie de persoon is. Authenticatie is daarom de eerste stap die moet worden uitgevoerd bij iedere aanvraag op de portalserver. Portal Access Control (PAC) definieert een set van gevoelige activiteiten die een eindgebruiker mag uitvoeren in zijn eigen gedefinieerde portaalomgeving. Deze set van activiteiten is gedefinieerd via de aan de gebruiker verleende autorisaties. Dit kan worden geregeld op basis van rollen, waarbij een set van autorisaties wordt gekoppeld aan een bepaalde rol in de organisatie.
Beveiliging gevoelige handelingen
Gebruikers interacteren met het portaal op allerlei manieren, variërend van het simpel browsen door informatieve pagina’s tot complexe handelingen zoals uitvoeren van software-updates, het aanpassen van portlets en bedrijfstransacties. Toegang van bijna elke soort van acties moet worden beperkt tot een groep van geautoriseerde gebruikers. Daarom zijn alle gevoelige handelingen beveiligd door het Portal Acces Control component, vergelijkbaar met Access Control voor elke standaard applicatie.
Portlet beveiliging
Portlets, of portal-applets zijn visuele, dynamische componenten die deel uitmaken van een webpagina van een web-portal. Normaal wanneer een gebruiker vraagt om een gepersonaliseerde webpagina, worden er meerdere portlets aangeroepen die samen de webpagina opbouwen. Een voorbeeld is een nieuwsportaal, dat in enkele pagina’s actueel financieel nieuws geeft, beursnieuws en de meest recente informatie over voorraden geeft die van belang zijn voor de eindgebruiker. Elke component beschikt daarbij over zijn eigen portlet. Portlets zijn gebaseerd op API’s, zoals gebruikersprofielen. Wegens het ontbreken van specifieke technische standaarden, leveren portalserver-leveranciers eigen API’s voor lokale portalcomponenten, die een uniforme beveiliging van lokale portlets ingewikkeld maakt.
Een oplossing is de toepassing van Java Virtual Machine (JVM) code, dat draait op de portal/webserver. De Java code volgens de J2EE specificatie, maakt gebruik van de LDAP gebruikersdatabase voor toegang tot de portlets. J2EE Platform beveiliging is echter ontworpen voor administratieve systemen en kan niet in alle gevallen voorkomen dat malicious portlet code het portaal beschadigt of dat gevoelige data ongeautoriseerd kan worden gelezen via een call vanuit andere interne portlets. Daarom moeten portlet-ontwikkelaars aanvullende maatregelen nemen in de vorm van geprogrammeerde controles om gevoelige data te beschermen en de betrouwbaarheid van het portaal als geheel te waarborgen.
Verificatie veilige verbinding
Portlets die een beveiligde verbinding vereisen, moeten de garantie krijgen dat de gegevens die ze versturen vertrouwelijk worden behandeld. Als het portaal TLS ondersteunt, dan kunnen portlets een TLS connectie opzetten via een “start transaction” link. Echter, het portlet moet wel controleren of de verbinding nog steeds veilig is, wat kan worden gedaan met de ‘request.is.Secure()’ methode. Als een portlet request niet via een beveiligde verbinding de portal bereikt, mag het portlet geen vertrouwelijke data versturen naar de aanvrager.
Voorkomen van Cross Site Scripting aanvallen
Omdat portlets rechtstreeks toegang hebben tot de ‘markup stream’ van de portal/web applicatie, worden ze blootgesteld aan Cross Site Scripting aanvallen net als alle andere webtoepassingen. Daarom is de portlet ontwikkelaar verantwoordelijk voor de juiste codering van alle gegevens voorafgaand aan de ‘markup stream’. Dit wordt meestal gedaan met behulp van een JSTL out tag vanuit JSP of met behulp van leverancier specifieke commando’s voor web applicaties. Om het risico van schade door aanvallen te verminderen, kan de portal engine zodanig worden geconfigureerd, dat het een aantal basis filteringen uitvoert op de portlet input. De karakters ‘kleiner dan’ en ‘groter dan’ worden geconverteerd tot de corresponderende HTML escape sequences. Met deze maatregel worden echter maar een beperkt aantal potentiële kwetsbaarheden opgelost. Soortgelijke problemen ontstaan ook wanneer een portlet markup van een andere server aggregeert.
WSRP beveiliging
Portalen kunnen Web Services for Remote Portlets (WSRP) protocol ondersteunen. Dit zijn z.g. remote portlets, die gebruikt kunnen worden als lokale portlets onder bepaalde restricties. WSRP wordt gebruikt, wanneer het portaal van een ‘klant’ (consumer) een verbinding legt met een portal van een ‘leverancier’ (supplier). Standaard worden WSRP verbindingen niet beveiligd. Er worden geen betrouwbare identiteiten uitgewisseld tussen de klant-leveranciers portalen. Daarom kan een portlet niet terugvallen op de betrouwbare gebruikersgegevens of referenties. Gepropageerde gebruiker metadata kan worden gebruikt om een gepersonaliseerde ‘user experience’ in te stellen, bijvoorbeeld door informatie over en weer te sturen op basis van de locatie (postcode) in het gebruikersprofiel-window. Echter, deze informatie moet meer als ‘hint’ worden opgevat voor de identiteit van de gebruiker dan als geverifieerde gebruikers identiteit.
Webserver-leveranciers ondersteunen voor deze toepassingen WSRP verbindingen die TLS ondersteunen, zodat man-in-the-middle aanvallen kunnen worden voorkomen.
Afwegingen
Portals, in de vorm van webapplicaties, zijn voor hun type beveiligingsmaatregelen in belangrijke mate afhankelijk van de web-technologie die binnen een organisatie gebruikt wordt en de architectuur die fabrikanten van web- en portal-technologie toepassen. Universele standaarden voor de mechanismen binnen een portaal zijn er nog niet, wat impliceert dat beveiliging van dit type webapplicatie voorlopig nog maatwerk is en dat we moeten kiezen uit wat de fabrikant ons biedt. Als gekozen wordt om zich te beperken tot marktleiders van web- en portaltechnologie, dan zijn er voldoende mechanismen leverbaar om portalen te kunnen beschermen.
Voorbeelden
Bedrijfsportalen van banken, verzekeringsmaatschappijen, reisbureaus en luchthavens.
Implicaties
Koppel portaalbeveiliging aan de binnen een organisatie gebruikte technologie voor webservices. Train applicatiebouwers op ‘secure programming’ en software testmethodieken. Zorg dat de mechanismen van applicatiecontroles worden gebruikt zoals invoer- en uitvoercontroles. Controleer portalen en de onderliggende code periodiek op kwetsbaarheden voor inbreuk en ongewenste mobiele code.