Praktische aanpak van theoretisch model

[X-DraGoN]

Bij een klant waar ik zit hebben ze een theoretisch model voor security te waarborgen binnen het netwerk.

Dit is reeds grotendeels omgezet naar een praktische kant, maar voor 1 onderdeel is mijn directe baas, net zoals ik, niet akkoord met de architect die het document heeft samengesteld.


De passage waar ik het over zou willen hebben is de volgende:

------------------------------------------------------------------------------

Beheerportalen (jumphost)

De systemen voor het beheer van de VFP infrastructuur zijn uitsluitend toegankelijk via de Juniper SSL/VPN remote access voorziening, die voor elke sessie sterke authenticatie vereisten (zie 4.4). Na succesvolle authenticatie krijgt de beheerder (afhankelijk van het gebruikersprofiel) toegang op het jumphost systeem waarvoor deze is geautoriseerd.

De jumphost is een virtuele client omgeving welke alle toepassingen bevat die nodig zijn voor het beheer van de systemen waarvoor de betreffende competentie cel de verantwoordelijkheid draagt.

Vooralsnog zijn de jumphosts geaccommodeerd op een VMware vSphere systeem, en kunnen de door VMware ondersteunde client OS varianten worden toegepast:

- Linux Redhat of OpenSuze

- Server 2008 R2

Via de SSL/VPN verbinding kan met een terminalserver protocol toegang worden verkregen op de jumphost. De volgende protocollen worden op het netwerk toegelaten:

- RDP

- VNC

De jumphost omgevingen worden tot op het niveau van het virtualisatie platform (VMware) beheerd door de dienst Systemen van de F&B ICT afdeling. Eventueel kan de Windows 7 user build worden gefaciliteerd. Echter, de gebruiker van de jumphost is zelf verantwoordelijk voor de inrichting en het beheer van de client omgeving.

Voor elke beheerder is in principe een exclusieve jumphost desktop omgeving beschikbaar. Er wordt echter we van uitgegaan dat dat voor elke competentie-cel een gemeenschappelijk OS build wordt toegepast, welke volgens de standaards van de betreffende organisatie is geconfigureerd. De Linux omgevingen kunnen wel worden gedeeld door meerdere gebruikers mits deze gebruik maken van een persoonlijk user-account.

Voor het gebruik van de jumphost gelden de volgende regels:

- Er mag uitsluitend programmatuur worden geïnstalleerd die voor de uitvoering van de beheer-taken noodzakelijk worden geacht.

- De gebruiker dient zelf zorg te dragen voor

o Regelmatige controle op virussen

o Effectieve security hardening van het OS

o Beheer van passwords

o Regelmatige software updates

- De autorisaties zijn strikt persoonlijk en mogen dus niet worden gedeeld met andere personen. Bij personele wijzigingen van de competentie cel kan contact worden opgenomen met het F&B Security Office.

--------------------------------------------------------------------------------------------------------------------------------

Over het bovenstaande gaat de vraag dus, hoe zouden jullie dit omzetten naar een werkbare en vooral beheersbare omgeving?

Mogelijkheden die ik reeds in gedacht heb gehad:

1: VMware View: Nadelen: - Geen Linux ondersteuning

- Hoeveel verschillende templates zouden nodig zijn voor veel verschillende profielen?

2: Jumphost (huidige oplossing): Verschillende VM's specifiek opgezet voor de verschillende personen (we zitten momenteel aan meer als 30 verschillende jumphosts)

3: ???

Hebben jullie nog suggesties? Mochten er eventueel nog vragen zijn, wil ik die ook wel beantwoorden.

[CMD-Snake]

Eventjes TL;DR. Jullie willen dus een (virtuele) werkplek waarop een beheerder enkel toegang heeft tot de systemen die hij/zij moet beheren.

Om daarvoor nou tigtallen VM's aan te maken vind ik persoonlijk overdreven. Het is onoverzichtelijk en je maakt mogelijk meer kosten aan licenties.

Veel bedrijven waar ik gewerkt heb kiezen ervoor om een terminal server in te richten voor beheer. Dit in het geval dat men liever niet heeft dat je vanaf je werkplek een rdp sessie opzet naar een server die je nodig hebt.

Je moet dan gewoon een terminal server maken, waarop je alle nodige software zet. Dus bijvoorbeeld Exchange Console, SQL Server Management Studio, de console van je AV oplossing, SCCM console, AD management tooling, noem maar op. De rechten handel je middels AD groepen af in het pakket zelf. Binnen veel pakketten kan je gewoon rechten aan groepen geven. Zo kan iemand wel een console starten, maar als hij/zij geen rechten heeft zal die persoon niets zien en niets kunnen doen. Of niet meer kunnen doen dan dat jij wil.

Wil je nog die terminal server personaliseren dan kan je nog iets als RES Workspace overwegen om icoontjes te verbergen. Maar goed, iets verbergen is geen vervanging voor goed rechten zetten binnen een product.

Een terminal server heeft kosten in de zin dat de licenties duurder zijn, maar je bespaard op resources. Een terminal server is denk ik minder een aanslag dan 30 of meer virtuele werkplekjes.

[Question Mark]

X-DraGoN schreef op woensdag 08 januari 2014 @ 12:00:
Dit is reeds grotendeels omgezet naar een praktische kant, maar voor 1 onderdeel is mijn directe baas, net zoals ik, niet akkoord met de architect die het document heeft samengesteld.

Waar ben je het exact nu niet mee eens? Dat er per beheerder een jumphost beschikbaar gesteld wordt?

Een vaak gebruikte oplossing is inderdaad 1 terminal server neerzetten, en die als opstappunt gebruiken naar de verdere interne systemen. Dus vanaf die terminal neem je met RDP je reguliere werkplek/beheerstation over.

[X-DraGoN]

Ik ben het niet eens met de aanpak van de verschillende jumphosts omdat die op den duur zouden leiden naar een onoverzichtelijk serverpark.
1 terminal server is an sich wel een oplossing maar als je dan weer verder denkt, hoe zit het dan met verschillende applicaties die al die verschillende gebruikers/ontwikkelaars willen hebben?
Hoe zit het met netwerk verbindingen die, ik geef toe niet in dit stukje voorkomen, maar ook apart zouden moeten zijn? (moet je al een Server voorzien met evenveel poorten als dat er VLAN's zijn)
Hoe ga je ervoor zorgen dat als iemand aanlogd alleen bepaalde programma's kan opstarten? (applocker?)
De verschillende gebruikers zouden ook 'beheerder' in hun eigen profiel moeten zijn, is daar een pasklare oplossing voor?
De gebruikers die erop zouden moet gaan werken zijn ontwikkelaars die meer gebruiken als maar wat MMC'tjes, Visual Studio, SQL Developper, Lotus Notes DEV, ... Applicaties die je toch niet wilt op een RD-Host, toch?

[Question Mark]

Een jumphost of stepping stone moet eigenlijk niet meer doen dan wat die naam zegt Het is een opstaphost naar je interne infrastructuur en geen werk-of beheersplek (let wel, dit is mijn persoonlijke mening).

De enige software die er in mijn ogen op zou moeten draaien zijn tools waarmee sessies naar interne systemen mogelijk zijn (RDP-client, putty, etc). Het daadwerkelijke beheer doet de beheerder maar vanaf zijn eigen interne beheersstation. Daar staat al zijn tooling op, en het netwerk is zo ingericht dat vanaf deze beheersplek netwerktoegang tot de verschillende interne systemen mogelijk is.

[CAPSLOCK2000]

Wij hebben 1 jumphost (plus een reserve) waar we met SSH op inloggen. Vanaf daar maken we verbinding met onze eigen desktop. Vanaf daar gaan we naar de servers. De meesten van ons hebben twee desktops, 1 voor serieus werk en een voor spielerij (nu.nl lezen enzo), die zitten in verschillende vlans.
Omdat het SSH is kunnen we de twee jumps automatisch laten uitvoeren en merk je er in praktijk niks van als je de juiste ssh-sleutels beschikbaar hebt.