VMM-infrastructuur Versie: Situering... 1

VMM-infrastructuur

Versie: 3.01

V M M - i n f r a s t r u c t u u r : Aa n p a k , richtlijnen en vereisten voor maat- en pakketsoftware 1

Situering .................................................................................................................................................................... 1

2

Software..................................................................................................................................................................... 1 2.1 Indeling toepassingen ......................................................................................................................................... 2 2.2 Aanpak VMM-maatsoftware (al of niet van ASW) ............................................................................................ 2 2.3 “MSI” achtergrond info ...................................................................................................................................... 5 2.4 ThinApp.............................................................................................................................................................. 6

3

Ontwikkel-, Test- en Productieomgeving................................................................................................................ 6 3.1 Ontwikkelomgeving............................................................................................................................................ 6 3.2 Testomgeving ..................................................................................................................................................... 6 3.3 Productieomgeving ............................................................................................................................................. 7

4

Hardware................................................................................................................................................................... 7 4.1 Principeopbouw van serverhardware .................................................................................................................. 7 4.2 Databankservers.................................................................................................................................................. 7 4.3 Citrixservers........................................................................................................................................................ 7 4.4 Vmware............................................................................................................................................................... 7 4.5 Principeschema van het netwerk......................................................................................................................... 8 4.6 WAN van de VMM ............................................................................................................................................ 8

5

Datacommunicatie- en beveiligingsvoorwaarden voor maat- en-pakketsoftware .............................................. 8 5.1 Algemeen............................................................................................................................................................ 8 5.2 Datastromen ........................................................................................................................................................ 9 5.3 Authenticatie....................................................................................................................................................... 9 5.4 Security ............................................................................................................................................................... 9

1 Situering In de periode 2005-2006 werd bij de VMM een “Windows Desktop Migratie”-project uitgevoerd. Hierbij werd er naast de omschakeling naar Windows XP als desktop besturingssysteem, de centralisatie van alle bestanden op de centrale bestandenserver op een SAN te Aalst en het aanbieden van centrale toepassingen via Citrix eveneens gestandaardiseerd naar beveiliging. Dit betekent concreet dat toepassingen (in elke vorm) aan bepaalde eisen moeten voldoen om te kunnen werken binnen de verstrengde en gestandaardiseerde veiligheidsvoorschriften van de VMM. Het vorige desktop besturingssysteem (Windows NT4.0) speelde nogal laks om met systeemzaken (o.a. veiligheid en stabiliteit). Het nieuwe desktop besturingssysteem (Windows XP SP2) is een stuk strenger wat systeeminstellingen en -componenten betreft en is daardoor robuuster en veiliger. Zowel de bestandenstructuur als het centrale register (registry) zijn extra beveiligd. Niettemin is het evengoed mogelijk alles te laten werken mits de inachtname van bepaalde regels. De strengere regels kunnen problemen veroorzaken voor oude toepassingen (of toepassingen gebaseerd op oude regels wat betreft plaats in bestandenstructuur en registergebruik). Er wordt bij de VMM uitgegaan van een situatie waarin de gebruiker, met gewone permissies (zoals door Microsoft voorzien in het gebruikersprofiel “standard user”), de toepassingen moet kunnen “gebruiken”! Daarnaast worden er bijkomende multi-user eisen gesteld aan de toepassing omwille van de gecentraliseerde Citrix-omgeving (Citrix MPS 4.0 RU4 op Windows 2003 SP2). Alle toepassingen dienen aangeboden te worden in MSI-formaat voor automatische installatie op zowel Windows XP (via GPO’s) als op Citrix (via CIM, de ingebouwde Citrix Installation Manager). Momenteel is er een project opgestart om te migreren naar een recentere versie van zowel het standaardbureauticapakket, het desktopbesturingssysteem en het citrixplatform (Office 2010/Windows 2008 x64/XenApp 6/XenDestop 4). Dit nieuw platform zal nieuwe eisen stellen aan hoe software zich dient te “gedragen”, in de tussentijd blijven alle eisen aan software voor de combinatie Windows XP/Office 2003/Windows 2003/Citrix MPS4 van kracht.

2 Software Afdeling Kennisbeheer–Team Systeembeheer, Tel. +32 (53) 72.62.62, Fax +32 (53) 70.04.29

1

VMM-infrastructuur

Versie: 3.01

2.1 Indeling toepassingen Voor de volledigheid van dit document wordt de aanpak beschreven die de VMM aanhoudt voor alle toepassingen. De toepassingen worden ingedeeld in hoofdcategoriën naargelang afkomst en functie: 2.1.1 “Commerciëel algemeen” Dit is een samenvoeging van toepassingen met dezelfde functies. Het betreft hier commerciële pakketsoftware van Microsoft, Adobe, ESRI, AutoDesk… Van de verschillende toepassingen wordt slechts één versie ondersteund en toepassingen met gelijkaardige functionaliteit worden geconsolideerd in één toepassing. Aanvragen voor een nieuwe versie dienen gemotiveerd te worden op de WG Databeheer. Deze toepassingen worden bij voorkeur via Citrix aangeboden en de installatiepakketten dienen dan ook voorbereid te zijn voor automatische installatie via GPO of CIM. Gebruik op Citrix houdt in dat de toepassingen gevalideerd en gecertificeerd door de fabrikant moeten zijn op “multiuser-gedrag” (zie verder). Dit is een voorwaarde voor aankoop en ondersteuning. 2.1.2 “Commerciëel dev-tools” Het betreft hier ontwikkelingstools die aangekocht werden voor het Team applicatiesoftware of andere programmeurs. Wegens de hoge complexiteit van dergelijke toepassingen en het relatief lage aantal installaties, zal hier geen automatische installatie voorzien worden. De ontwikkelsoftware zal dus manueel geïnstalleerd worden door door applicatiesoftware. 2.1.3 “Commerciëel technical” Het betreft hier software die bij bepaalde toestellen hoort, meestal direct aan de computer gekoppeld. De installatie van de pakketten zal enkel op desktops of portables gebeuren en hiervoor zal, indien mogelijk, een automatische installatie voorzien worden. Een overschakeling naar andere versies wordt niet voorgesteld door systeembeheer aangezien het toestel de bepalende factor voor de toepassing is. Nieuwe versies kunnen noodzakelijk zijn i.h.k.v. onderhoud en upgrades van het besturingssysteem. 2.1.4 “VMM-maatsoft ASW” Deze set van toepassingen is kritisch voor de VMM en vereisen een aparte aanpak. Weinig toepassingen vervallen en het samenvoegen van functionaliteit is ook niet mogelijk. Toepassingen die extern ontwikkeld werden, maar naderhand door applicatiesoftware te onderhouden zijn, vallen eveneens in deze categorie. Deze toepassingen dienen altijd op Citrix te werken met automatische installatie via CIM. Het aanbieden via Citrix houdt in dat toepassingen gevalideerd moeten worden op “multiuser-gedrag” (zie verder). Ook bij de opmaak van lastenboeken en beoordeling van offertes van aannemers moet daarmee rekening mee gehouden worden! 2.1.5 “VMM-maatsoft non-ASW” Deze toepassingen zijn specifiek voor VMM, maar zijn niet aangeleverd of onderhouden door ASW. Deze toepassingen kunnen zowel bij de VMM (niet-applicatiesoftware) ontwikkeld zijn maar evenzeer bij externe bedrijven. Onder deze categorie vallen de belangrijkste bij de VMM ontwikkelde VB(A)-, en Accesstoepassingen. Andere toepassingen, van externe bedrijven, zijn bijv. de Cevi-, Cipal- en Adifo-toepassingen. de Deze toepassingen worden bij voorkeur aangeboden via Citrix, pas in 2 instantie worden ze op desktop (pc’s) geïnstalleerd. Het aanbieden via Citrix houdt in dat toepassingen gevalideerd moeten worden op “multiuser-gedrag” (zie verder). Ook bij de opmaak van lastenboeken en beoordeling van offertes van aannemers moet daarmee rekening mee gehouden worden! Deze toepassingen dienen altijd op Citrix te werken met automatische installatie via CIM. 2.1.6 “VMM-Middleware” Dit betreft alles wat, in ruime zin, met middleware te maken heeft. Het gaat dus om meer dan enkel de componenten voor toegang tot databanken, ook bepaalde VB-dll’s, client-managers, common ini-files, … . Een uitvoerige beschrijving van de aanpak is terug te vinden in een apart document (VMM middlewareframework). 2.1.7 Algemeen De benaming van de toepassingen bestaat steeds uit 3 delen: -<product-name>-: : firma, organisatie of maker programma (bij VMM-apps is dat steeds “VMM”) <product-name>: de naam van het programma (bijv. emissie-afvalwater) : de versie. 2.2 Aanpak VMM-maatsoftware (al of niet van ASW) 2.2.1 Algemeen Afdeling Kennisbeheer–Team Systeembeheer, Tel. +32 (53) 72.62.62, Fax +32 (53) 70.04.29

2

VMM-infrastructuur

Versie: 3.01

Alle toepassingen dienen opgelijst te worden met telkens de bijhorende “dependencies” (zie .2.2.1.1). Dat kan gaan over bepaalde dll’s, middleware, plug-in’s, ... . Dat is niet altijd even vanzelfsprekend. Sommige componenten (dll’s, ocx-en, …) staan bv. wel al op de computer van programmeurs (want meegeïnstalleerd met andere pakketten of de ontwikkelsoftware), maar daarom nog niet op de computers of servers waarop het ontwikkelde programma uiteindelijk moet draaien. De dependencies moeten in één document komen en aan systeembeheer bezorgd worden. Een reeds bestaand document per toepassing voor de eindgebruiker (bv. een installatie- of gebruikershandleiding) is daarvoor niet voldoende. Het moet gaan om een specifiek document waarin beschreven wordt wat het platform extra moet bieden aan de toepassing. Na dat werk dient de ontwikkelaar het pakket voor te bereiden op de nieuwe omgeving (zie .2.2.1.2). Zoals eerder gesteld is Windows XP (en Windows 2003 met Citrix) een stuk strenger en dienen bepaalde richtlijnen (“Windows XP Logo Program”) in acht genomen te worden (zie verder). Tenslotte dient de toepassing getest te worden in een zo representatief mogelijke omgeving (zie .2.2.1.3). Een toepassing dient altijd te kunnen werken op Windows XP, wat altijd een eerste test zou moeten zijn. Op Terminal Server (Citrix) moet de toepassing getest worden op multi-user gedrag. .2.2.1.1

.2.2.1.1.1

Oplijsting van toepassingen + beschrijving van “dependencies”

Delphi/Omnis (ASW)

Het Team systeembeheer verwacht van de ontwikkelaars dat alle Delphi/Omnis-toepassingen overzichtelijk opgesomd worden in één document. Er dient telkens een vermelding van de “dependencies” te komen, waaronder vooral ook de middleware. Het is noodzakelijk dat de middleware nauwkeurig vermeld wordt, aangezien systeembeheer voor die installatie zal instaan. Enkele voorbeelden van het vereiste detailniveau: - toepassing “GWIP”: - dependent runtime: OMNIS 73 v7.0.2 runtime - middleware software: MDAC 2.8 SP1 + Informix 2.81 TC2 - middleware db -configuratie: ODBC 0toepassingen, 0water, 4toepassingen en 4water - toepassing “HeffingenGV”: - dependent app: Microsoft Word 2000 of 2003 - dependent hardware: handscanner op seriële poort - middleware software: MDAC 2.8 SP1 + Informix 2.81 TC2 + Microsoft Jet 4.0 + Microsoft XML4 EN SP2 + Barcode-fonts - middleware db-configuratie: ODBC ...; BDE 0Heffingen, BDE 2Heffingen, ... Let op, informatie als “xlkjd.dll” is benodigd voor het correct draaien van de toepassing” wordt niet aanvaard. Dergelijke bibliotheken zijn bevat in middleware pakketten en dienen als dusdanig te worden bekeken. De Delphi/Omnis-toepassingen zullen allemaal “gerepackaged” moeten worden door de leverancier van de toepassing. De “repackager” haalt uit de “legacy-setup” componenten uit die apart geïnstalleerd dienen te worden, die gemeenschappelijk zijn voor verschillende toepassingen of die overbodig zijn. De middleware-componenten (drivers + configuratie) zijn altijd apart te installeren. De opmerkingen komen in een documentje. Het Team systeembeheer zal na packaging en installatie van de middleware-componenten zelf instaan voor een beperkte technische test: de opstart van de toepassing en de logon (op test en productie). De verdere functionele testen moeten door het Team applicatiesoftware en “key-users” gebeuren. De repackaging verandert niets aan de software zelf waardoor het resultaat van de testen gedeeltelijk voorspeld worden.

.2.2.1.1.2

Web (van ASW of andere oorsprong)

Het Team systeembeheer verwacht van alle ontwikkelaars dat ook de web-gebaseerde maatsoftware overzichtelijk opgesomd worden in één document. Er dient eveneens telkens melding gemaakt te worden van de “dependencies”. Sommige vereisen bv. een Java-runtime, Excel, Word, … . Indien een plug-in een specifieke versie moet zijn moet dat ook vermeld worden. Ook specifieke browserinstellingen kunnen de werking beïnvloeden en dienen daarom vermeld te worden.

.2.2.1.1.3

Toepassingen van andere oorsprong

Het Team systeembeheer stelt dezelfde eisen aan alle leveranciers van software, dus zoveel mogelijk detail van vereiste dll’s, achtergrond-toepassingen, plug-in’s, instellingen, ... . Het Team systeembeheer verkiest een aangeleverd pakket in MSI-formaat, maar kan toepassing aangeleverd in afzonderlijke componenten (dll’s, ocx’en, ...) of in de vorm van een “legacy-setup” (in niet MSI-formaat) gedogen. .2.2.1.2 Algemene eisen aan aangeleverde software Het Team systeembeheer stelt een aantal zaken ter beschikking: - Roaming-profiles: het Windows-platform maakt gebruik van beperkte “roaming profiles” op de Citrixservers. Hiermee kunnen instellingen (in registry, ini-files, …) en bestanden (shortcuts, …) meegaan naar de server(s) waarop de gebruiker werkt. De beperkte “roaming profiles” houden in dat er

Afdeling Kennisbeheer–Team Systeembeheer, Tel. +32 (53) 72.62.62, Fax +32 (53) 70.04.29

3

VMM-infrastructuur

Versie: 3.01

slechts een aantal zaken in roaming komen , bv. internet favorieten, cookies, instellingen van Outlook, … . - Een L-schijf: dezelfde schijfletter zal er zijn voor Windows XP als onder Citrix (wat standaardisatie toelaat), maar de inhoud ervan zal gescheiden zijn! - Middleware-omgeving: de middleware komt uitgebreid aan bod in een specifiek document (VMM Middleware-framework-vx.y). Het beheer van de middleware ligt bij het Team systeembeheer, aangezien dit een basis is voor alle programma’s die bij de VMM moeten (samen) werken. Het Team systeembeheer verwacht van het Team applicatiesoftware en andere programmeurs uniformiteit i.v.m. benamingen: - in het register wordt (onder “software”) altijd de hoofdkey “VMM” (zonder punten ertussen!) gehanteerd, zowel onder HKLM als onder HKCU. Onder HKLM komen zaken die op de gehele computer betrekking hebben (bijv. toepassing-versie), onder HKCU komen zaken die betrekking hebben op de aangemelde gebruiker (bijv. een pad naar een map waar het laatst een document opgeslaan werd, een printerkeuze of papierlade, … - voor het wegschrijven onder de verschillende folderstructuren, wordt eveneens vmm gebruikt, dus niet “vmmware” - in tijdelijke bestanden, “lokale tabellen” of het register altijd en overal de eigen “globalisatieregels” respecteren. Bijv. nergens nog “oppervlaktewater” maar steeds “immissie-oppervlaktewater”. Een afkorting daarvan kan ook (bijv. “imm-oppl”), maar dan steeds dezelfde. Gezien het standaard strengere beleid op Windows XP/2003 dient er daar vooraf al mee rekening gehouden te worden. Microsoft heeft een specifiek document gepubliceerd met te volgen “richtlijnen” om programma’s goed te laten werken, meer bepaald het document “Designed for Microsoft Windows XP”. Het document is algemeen van aard en bedoeld voor (commerciële) software-leveranciers. Een kopie staat ter beschikking in de AOP-map voor alle programmeurs. Het Team systeembeheer gaat ervan uit dat de richtlijnen gevolgd worden. Ter informatie: de meeste problemen vloeien voort uit ondertussen totaal achterhaalde en verkeerde gewoontes uit de Windows 3.1-wereld! Hierna volgt een opsomming van de meest bekende problemen: - gebruik van “hard-coded” paden: paden dienen altijd “relatief” te zijn, en indien er moet naartoe geschreven worden dan moet ook de verwijzing daarmee rekening houden. Ook het programma zelf mag niet verwachten in een specifieke map te zitten. Bijv. mag de toepassing “emissie-afvalwater” niet verwachten in de map te staan onder “c:\vmmware\...”. - Op Windows XP-computers komen de programma’s onder “G:\Apps\” te staan. Op Citrix-servers komen de programma’s onder “F:\Apps\” te staan. Enkel ter info dus, de programmeur mag deze paden niet vast in de programma’s verwerken! - Niet kunnen werken met lange padnamen. Meestal is de oorzaak een gehele of gedeeltelijke aanwezigheid van 16bit-code, deze toepassingen worden zo mogelijk geweigerd wegens diverse moeilijkheden - Geen gebruik maken van “environment variables”: tal van “environment variables” staan al langer ter beschikking om het gebruik van “absolute paden” te kunnen vermijden. De set variabelen is onder Windows XP (en Citrix-servers) uitgebreider dan onder Windows NT4. Het gebruik ervan zou maximaal moeten zijn, daarom volgt hieronder een lijstje met de meest interessante ervan voor programmeurs: - “CommonProgramFiles”: verwijst naar “C:\Program Files\Common Files”, voor het wegschijven van gemeenschappelijjke files van een specifiek bedrijf of organisatie. Wegschrijven gebeurt enkel bij installatie van programma’s. Het Team systeembeheer zal voorzien in een subfolder “VMM” voor VMM-specifieke zaken (bv. middleware-configuratie). Deze componenten zijn niet uniek per programma en zullen daarom altijd blijven staan na een uninstall van een programma. - “appdata”: voor toepassing-specifieke bestanden (wegschrijven wijzigbare tijdelijke data horend bij een toepassing). Deze variabele verwijst naar een specifieke plaats per gebruiker (C:\Documents and Settings\<username>\Application Data) waar verder een structuur kan opgebouwd worden per softwareleverancier. Alle VMM-maatsoftware dient onder de naam “VMM” te komen. Dit mag enkel gebruikt worden voor heel kleine hulpbestanden, vermits deze locatie mee opgenomen wordt in het roaming profile en dus bij elke logon gekopieerd wordt!. - “homedrive” en “homepath”: via centrale instellingen zal de verwijzing van “homedrive” steeds gebeuren naar “P:”, en “homepath” steeds naar “\”. Dat zal zowel het geval zijn op Windows XP als op Citrix! - “clientname”: hier staat steeds de (DNS-naam) name van de computer. Deze naamgeving is gestructureerd en bestaat uit een prefix per locatie, een streepje en een oplopen nummer. bv. “GAS” voor computers van Aalst. Voor Citrix-servers begint de naam steeds met “MAIN”. - “sessionname”: hierop kan een detectie gebeuren of de toepassing in multi-user mode moet werken of niet. Op Windows XP-computers is dat steeds “Console”, binnen een Terminal Server-sessie begint de variabele steeds met “RDP-...” en binnen een Citrix-sessie is begint deze steeds met “ICA…” Afdeling Kennisbeheer–Team Systeembeheer, Tel. +32 (53) 72.62.62, Fax +32 (53) 70.04.29

4

VMM-infrastructuur

-

-

-

-

-

-

Versie: 3.01

“temp” (of “tmp”): voor wegschrijven op de lokale hard-disk van tijdelijke bestanden. Er kan absoluut geen gebruik meer gemaakt worden van “C:\temp”, deze folder bestaat niet meer! De bestanden die tijdelijk naar %temp% weggeschreven worden mogen redelijk groot zijn, aangezien deze folder niet mee genomen in het roaming-profile. De door het programma gecreëerde files in %temp% moeten na afsluiten van het programma steeds verwijderd worden! De programma’s mogen niet verwachten dat bij de volgende opstart er daar nog iets van een vorige keer teruggevonden kan worden. verkeerd gebruik maken van de registry-keys “HKLM” en “HKCU”: deze keys hebben een specifiek doel en moeten correct gebruikt worden. “HKLM” dient vooral voor algemene gegevens m.b.t. het programma, zoals versie-info, standaard-instellingen, ... . “HKCU” dient voor user-gebonden zaken, zoals gemaakte menukeuze’s, kleurinstellingen, laatste keer opgestart, pad naar lokatie van data, ladekeuze van een printer voor bijv. speciaal papier, ... . Een gewone gebruiker heeft geen schrijfrechten op “HKLM”, wat ook zo hoort te zijn. verkeerd gebruik maken van de bestandenstructuur: nogal wat programma’s proberen zaken weg te schrijven die niet toegankelijk zijn voor een gebruiker met normale gebruiksrechten. Bijv. de logging voorzien naar het pad “c:\” is niet mogelijk verkeerd gebruik maken van de bestandenstructuur: toepassingen proberen soms output-data weg te schrijven naar een vast gecodeerd pad in een submap van de toepassing. De toepassing moet er steeds in voorzien de gebruiker de vrije keuze te geven waar gegevens terecht moeten komen (op een map naar keuze op server). Deze keuze kan weggeschreven worden in de HKCU. het veelvuldig en/of verkeerd gebruik maken van ini-files, het gebruik ervan is sowieso te vermijden. Indien ze toch gebruikt worden, moet dit op een correcte manier zijn, ttz. (systeem-) instellingen, die eerder bij de installatie of de computer horen, moeten in een andere ini-file terechtkomen dan de gebruikersinstellingen. Gebruikersinstellingen moeten terechtkomen in een ini-file die weggeschreven wordt op een plaats waarop de gebruiker schrijfrechten heeft (profiel van de gebruiker). het wegschrijven naar “Windows Protected zone’s”: Windows XP laat niet meer toe dat er tal van dll’s weggeschreven worden naar de system-folder (c:\windows\system32). Deze zone is beschermd om een oplossing te bieden aan de zogenaamde “DLL-hell”. In de plaats moeten dll’s die bij programma’s horen terecht te komen onder de eigen folder of een andere gemeenschappelijke folder (zoals bijv. “C:\Program Files\Common Files\Borland Shared” voor de gemeenschappelijke zaken van Borland).

.2.2.1.3 Toepassingen testen op een zo representatief mogelijke omgeving Het testen van software dient te gebeuren op een zo representatief mogelijke omgeving, het is dus van zeer groot belang dat dit een systeem is waarop de ontwikkelsoftware, of delen ervan, niet aanwezig is. Het Team systeembeheer stelt testomgevingen onder Citrix ter beschikking aan programmeurs (zie ook 3). .2.2.1.4 Belangrijke opmerkingen: Veel programmeurs beschikken over verhoogde gebruikersrechten om het programmeerwerk te verrichten. Sommige beschikken zelfs (al of niet tijdelijk) over installatierechten en hebben de neiging dan daarmee te testen. Deze testen zijn waardeloos om eerder vermelde redenen en worden dus niet geaccepteerd. Het testen dient te gebeuren met een gewone gebruikers-account die nog nooit eerder verhoogde rechten heeft verkregen! Daarom voorziet het Team systeembeheer in test-accounts met de naam “test-v.achternaam”. Alle testen van maat- en pakketsoftware dienen hiermee te gebeuren. Het Team systeembeheer doet slechts een heel beperkte (technische) test van toepassingen: - gewone toepassingen: opstarten van de toepassing en enkele menu’s doorlopen, eventueel openen van een bestand - toepassingen met aanlogprocedure op een database: opstarten van de toepassing en uitvoeren van de aanlogprocedure. De aanlogprocedure zal gebeuren op de verschillende databanken (voor zover er een gebruikersnaam en paswoord ter beschikking gesteld werd). Het verder testen van de toepassing wordt beschouwd als zijnde “functioneel” of “inhoudelijk” testen en dit dient uitgevoerd te worden door andere mensen (key-users, applicatieverantwoordelijken, referentiegebruikers, ...). In geen geval kan van het Team systeembeheer een inhoudelijke kennis van de toepassingen verwacht worden! Dit geldt eveneens voor het testen en aanpassen van Accessbestanden. 2.3 “MSI” achtergrond info Het Team systeembeheer wil zoveel als mogelijk automatische installaties kunnen uitvoeren. Het installatiesysteem werkt enkel op basis van MSI-pakketten. Deze MSI-pakketten worden op Windows XP toestellen verdeeld via GPO’s en op Citrix via de ingebouwde CIM (Citrix Installation Manager). Een MSI-pakket is feitelijk een database in de vorm van een bestand dat alle elementen bevat (of kan bevatten) die nodig zijn om een toepassing op een computer te krijgen. Leveranciers van maatsoftware dienen hun toepassing aan te bieden onder de vorm van een MSI- pakket. Afdeling Kennisbeheer–Team Systeembeheer, Tel. +32 (53) 72.62.62, Fax +32 (53) 70.04.29

5

VMM-infrastructuur

Versie: 3.01

Dergelijke native MSI-pakketten kunnen door het Team systeembeheer gemanipuleerd worden via een “MSI Transform” (MST), waarin alle antwoorden op de keuzes die normaal via dialoogvensters gesteld worden, vervat zitten. Het installatiepad voor MSI-pakket is verschillend op Citrix en op Windows XP, wat opgevangen d.m.v. verschillende MST’s naargelang het platform waarop het geïnstalleerd wordt. De leverancier van de toepassing moet steeds bij inschrijving al melding maken van alle dependencies (zie ook eerder). In de regel is alles wat geen eigen code is een dependency! De leverancier van de toepassing mag absoluut geen “redistributables” in een eigen “native” MSI verwerken. Eventuele redistributables moeten steeds apart aangeleverd worden. Bij de VMM zijn die er meestal al, al of niet in een afwijkende versie (bijv. .Net Framework 1.1). Het MSI-pakket mag absoluut geen extra scripts of andere installatie-hulpmiddelen zoals ISScript nodig hebben of bevatten. De Installer-property “INSTALLDIR” moet steeds correct gebruikt worden om de VMM toe te laten de toepassing op een pad naar keuze te installeren. Andere installatietechnieken (zogenaamde “legacy setups”) vereisen aanzienlijk meer voorbereidingswerk, dan moet nl. het MSI-pakket volledig zelf gemaakt worden. De aanmaak van een MSI-pakket kan vrij ingewikkeld zijn. Veel applicatie-leveranciers zijn trouwens zelf niet in staat dat tot een goed einde te brengen. Ofwel besteden ze dat dan zelf uit of hebben ze de neiging af te komen met een half-afgewerkt pakket (met een ellenlange manuele installatieprocedure. Elke maat- en pakketsoftware die bij de VMM binnenkomt (via het Team applicatiesoftware, maar evengoed via anders Team’s!) dient daarom aan een evaluatie-onderzoek onderworpen te worden. De kwaliteit van dat pakket is mede bepalend voor acceptie van de toepassing. Opgelet: een installatiepakket dat “native MSI” aangeleverd werd, zal nooit in een nieuw MSI-pakket gestoken worden door het Team systeembeheer, dit om geen conflicten te generen tussen het eigen MSIpakket en latere updates van de leverancier. Het belang van kwaliteitsvolle MSI-pakketten aangeleverd door leveranciers kan daarom niet genoeg benadrukt worden in lastenboeken. Daarnaast, eigenlijk los van het MSI-verhaal, eisen wij als VMM-opdrachtgever bepaalde normen (in het bijzonder voor toepassingen in de categorie “VMM-maatsoft ASW” en “VMM-maatsoft non-ASW”). Het Team systeembeheer zal die normen niet zelf beschrijven, maar verwijst daarvoor logischerwijze naar publiekelijk beschikbare documenten op het internet (Microsoft website). Eerder werd al zo’n document vermeld, nl. het document “Windows XP Logo Program”. Gezien het standaard platform voor toepassingen bij de VMM Terminal Server/Citrix server is, dienen zeker de VMM-toepassingen “multi-user” te zijn. Op het internet zijn talrijke document met richtlijnen voor software-ontwikkelaars beschikbaar. Het Team systeembeheer verwacht dat de ontwikkelaars zich op eigen initiatief informeren over de nieuwe ontwikkelingen en daarmee maximaal rekening mee houden. 2.4 ThinApp Sommige toepassing kunnen niet herschreven worden of vragen zeer veel werk om te packagen. Bijvoorbeeld toepassingen met een activatiecode die dynamisch bepaald wordt a.d.h.v. unieke systeeminformatie. Deze toepassingen kunnen dus, zonder de nodige aanpassingen, niet automatisch verdeeld worden over verschillende werkstations. De manipulaties voor een MSI-pakket zijn niet altijd succesrijk en voor dergelijke toepassingen kan er gepoogd worden om ze aan te bieden via ThinApp, waarbij ze in een gevirtualiseerde “bubble” draaien op een PC/server. De instellingen van deze “bubble” zijn op alle toestellen identiek.

3 Ontwikkel-, Test- en Productieomgeving Projecten voor nieuwe maat- en pakketsoftware dienen gebruik te maken van een 3-omgevingenmodel: ontwikkel, test en productie. De voornaamste eigenschappen van elke omgeving worden hieronder opgesomd. 3.1 Ontwikkelomgeving Dit is de omgeving waarin de toepassing ontwikkeld wordt, hier wordt gebruik gemaakt van lokaal geïnstalleerde ontwikkeltools en verhoogde rechten en toegangen voor de ontwikkelaar. De eerste (technische) testen gebeuren eveneens op deze omgeving. In het geval van pakketsoftware is deze omgeving aan te raden, maar niet strict noodzakelijk. 3.2 Testomgeving Dit is de omgeving waarin de toepassing inhoudelijk getest wordt door Informatica en inhoudelijk verantwoordelijken. Op deze omgeving is niets van de originele ontwikkelsoftware voorhanden Deze omgeving is onderhevig aan dezelfde beperkingen en softwareversies als de productieomgeving. In het geval van databankbevragingen dient van de databankomgeving eveneens een testomgeving voorzien te worden.


6

VMM-infrastructuur

Versie: 3.01

3.3 Productieomgeving Na doorlopen van inhoudelijke testen en schriftelijke acceptatie van de toepassing door key-users, inhoudelijke testers e.d. wordt de toepassing op de productieomgeving geplaatst en opengesteld naar de gebruikers.

4 Hardware 4.1

Principeopbouw van serverhardware

De serverinfrastructuur van de VMM is opgebouwd volgens het bovenstaand schema. Er wordt omwille van energetische, flexibiliteit en modulariteit geopteerd om te werken met Blade Servers i.p.v. standaard rackservers. Deze laatste worden enkel getolereerd indien de toepassing dit vereist (bv. specifieke insteekkaart). Voor het gebruik van USB-sleutels wordt gebruik gemaakt van AnywhereUSB-devices. De respectievelijke toepassing moet hiermee compatibel zijn. Alle Blade Centers zijn redundant uitgebouwd (redundante voeding, redundante interne netwerswitches en redundante interne SAN-switches), de connecties van de interne netwerken SAN-switches naar de redundante backbone verlopen eveneens over verschillende paden. De blade servers maken maximaal gebruik van deze redundantie. De Blade Servers worden typisch uitgerold via het boot-from-san principe waarbij er geen gebruik wordt gemaakt van lokale disken, maar van LUN’s op een centraal storagesysteem. Indien de toepassing dit vereist, wordt van dit principe afgeweken (bv. domain controllers). De verschillende storagesystemen van de VMM zijn geconsolideerd via een Storage Volume Controller. Indien de noodzakelijke opslagcapaciteit te groot is, kan hiervan afgeweken worden door LUN’s rechtstreeks via een storage controller aan te bieden (bv. de diskpool van de back-upserver). De VMM maakt eveneens maximaal gebruik van Low-Voltage processoren in zijn servers i.p.v. de iets snellere, maar veel meer verbruikende standaardprocessoren (bv. 50à 60W per processor i.p.v. 100 à 120W per processor). 4.2 Databankservers De databankservers en ondersteunende systemen draaien via Boot-From-SAN op SUSE Linux. De standaard database bij de VMM is Informix 11. 4.3 Citrixservers De Citrixservers draaien op Citrix Metaframe Presentation Server 4.0 RU6 en Windows 2003 SP2. 4.4 Vmware De VMM maakt gebruik van een VMwareomgeving gebaseerd op vSphere Enterprise en beheerd door vCenter. De VMwareomgeving is opgebouwd volgens bovenstaande hardwareprincipes. Op deze Vmwareomgeving wordt naast de volledige cyclus van ontwikkel-, testen productieomgevingen voor maat-, pakket- en rapporteringssoftware ook andere productiesystemen (printservers, Blackberry, SCBA, CEVI, Citrix, ...) aangeboden.


7

VMM-infrastructuur

4.5

Versie: 3.01

Principeschema van het netwerk Buitendienst x

Telenet WAN Internet

Printer

Mail Relay DMZ Public Exchange Cluster Databankservers Centrale Firewall

DMZ Private

Proxy Servers (forward/reverse)

Citrix Servers Trust Servers Domain Controllers

Web Server

VMware Servers Trust Clients File Server Cluster

Printer

Het principeschema hierboven toont hoe het netwerk van de VMM opgesplitst is zonder onnodig te detailleren en toont ook de locatie van een aantal essentiële netwerkcomponenten. Het netwerk te Aalst is opgesplitst in 4 grote zones en een aantal kleinere met specifieke toepassingen. De 4 zones zijn de volgende: - Trust clients: hierin bevinden zich alle PC’s, printers en plotters van Aalst en via VLAN’s ook deze van de buitendiensten. - DMZ Public: hierin bevinden zich alle servers die rechtstreeks vanaf het internet bereikt kunnen worden (bv. het SFTA-systeem voor versturen van grote bestanden en de reverse proxy voor de websites van de VMM) - DMZ Private: hierin bevinden zich alle servers die rechtstreeks naar het internet dienen te gaan (bv. de forward-proxy van de VMM) - Trust Servers: hierin bevinden zich alle servers (Citrix, DNS, DHCP, ...) - Al deze zones zijn getermineerd op een redundante firewall te Aalst die enkel de datastromen die nodig zijn toelaat. Alle andere datastromen worden tegengehouden. 4.6 WAN van de VMM Het WAN van de VMM is uitbesteed aan de firma Telenet en bestaat uit een combinatie van glasvezelverbingen, xDSL en Coaxverbindingen. Alle verbindingen zijn geïmplementeerd d.m.v. MPLS (Multi Protocol Layered Switching), waarop QoS van toepassing is.

5 Datacommunicatie- en beveiligingsvoorwaarden voor maat- en-pakketsoftware 5.1 Algemeen Het Team systeembeheer van de VMM heeft als doel nu en ook in de toekomst de ondersteuning van de VMM-toepassingen zo goed mogelijk te garanderen. De grote problematiek hierbij is dat het Team systeembeheer betreffende bepaalde –bestaande- toepassingen over onvoldoende info qua datacommunicatie beschikt. Andere toepassingen zijn dan weer niet opgezet zoals dit in feite zou moeten Afdeling Kennisbeheer–Team Systeembeheer, Tel. +32 (53) 72.62.62, Fax +32 (53) 70.04.29

8

VMM-infrastructuur

Versie: 3.01

zijn. Om dergelijke problemen voor toekomstige projecten/applicaties te vermijden, volgt hierna een oplijsting van een aantal zaken waaraan nieuwe projecten/ontwikkelingen op het gebied van datacommunicatie moeten voldoen. Enkel bij schriftelijke toestemming van het Team systeembeheer van de VMM mag er van bepaalde zaken in dit document afgeweken worden 5.2 Datastromen Het Team systeembeheer moet een gedetailleerde beschrijving (inclusief gebruikte protocol, poorten, source, destination, feit of al dan niet natting noodzakelijk is…) verkrijgen van alle communicatiestromen die de toepassing nodig heeft. Dit document is zeer gedetailleerd en is op de volgende manier opgebouwd: TrustServer x abc.def.ghi.jkl DMZ-private Server y mno.pqr.stu.vwx tcp_80 servers tcp_443 udp_80 DMZ-public Server x abc.def.ghi.jkl Untrust Server y mno.pqr.stu.vwx tcp_80 tcp_443 Dit document wordt ruim op voorhand voorgelegd aan het Team Systeembeheer ter controle en bij aanvaarding door het Team Systeembeheer worden de afgesproken policies geïmplementeerd op de centrale firewall. Op deze manier wordt een, voor beide partijen, tijdverliezend ad-hoc en trial-en-error proces vermeden om de datastromen herstellen. Het Team systeembeheer wenst steeds te beschikken over een up-to-date netwerkschema van de datastromen van de toepassing. Indien er nieuwe datastromen noodzakelijk zijn, dan wordt het vernieuwde document ter goedkeuring voorgelegd. De datastromen moeten overweg kunnen met gangbare controles en acties op “moderne” firewalls, routers, switches, proxies, load-balancers en andere. Hierbij denken we vooral aan zaken zoals het gebruik van tcp-keep-alives, statefull inspection, application layer gateway, intrusion detection systems en dergelijke. Vooral aan het correct gebruik van tcp-keep-alives dient de nodige aandacht besteed te worden. De toegang naar internet vanuit toepassingen en servers wordt enkel toegelaten over poorten tcp_80 (http) en tcp_443 (https) en dit over een forward proxyserver waarop de interne gebruikers zich authenticeren via NTLM. Andere vormen van authenticatie op deze proxy worden niet toegelaten. Webtoepassingen en/of toepassingen die naar internet gaan, moeten zowel overweg kunnenmet zowel een transparente proxy-opstelling als een expliciete (manual proxy configuration, automatic proxy configuration url, autodetect proxy settings for this network). Ook in deze gevallen moet er gewerkt kunnen worden met NTLM-authenticatie. Het gebruik van de forward proxyserver is verplicht en hiervan wordt niet afgeweken. Alle webtoepassingen die zich intern in het vmm-netwerk bevinden en waarop er via een webbrowser geconnecteerd moet worden, moeten zich in een daarvoor voorzien firewall-zone bevinden (trust-server, dmz-public of dmz-private). Deze webservices worden niet gehost in firewall-zones die voorzien zijn voor client-pc’s. Ook hier geldt dat er enkel (web)verkeermogelijk mag zijn –via een forward proxy- naar poorten tcp_80 (http) en tcp_443 (https). Toepassingen die aangeboden worden aan externe partijen (publiek internet of VPN’s zoals VONet), moeten voorzien zijn van mechanismen die bandbreedtebeperkingen aanbieden. Toepassingen moeten eveneens de mogelijkheid hebben om het caching behaviour (in proxy, client, e.a.) in te stellen. 5.3 Authenticatie Voor authenticatie van gebruikers wordt gebruik gemaakt van Active Directory waarbij group membership op een correcte manier toegepast dient te worden. Voor toepassingen die aangeboden worden via het publieke internet wordt geen koppeling met Active Directory toegelaten. Hoervoor dienen andere mechanismen voorzien te worden (bv. locale accounts, ADAM of ADLDS). Op termijn zal eID ingezet kunnen worden. 5.4 Security Zwakke protocollen dienen vermeden te worden. Hierbij wordt hoofdzakelijk gedacht aan niet geëncrypteerd verkeer (echter niet beperkend). De protocollen telnet, ftp, snmp v1 & v2… moeten respectievelijk vervangen worden door ssh, sftp/scp, snmp v3… m.a.w. geëncrypteerde communicatiestromen. Het gebruik van externe weblogins voor authenticatie via http wordt niet aanvaard en dient vervangen te worden door een authenticatie via https d.m.v. een publiek SSL-certificaat (GlobalSign, VeriSign, …). Interne weblogins dienen via een intern SSL-certificaat beveiligd te worden. Gevoelige informatie mag enkel in een geëncrypteerde vorm over het internet en of het VMM-LAN getransporteerd worden. Encryptie dient eveneens te gebeuren a.d.h.v. een publiek SSL-certificaat. Account-info (paswoorden) in configuratiebestanden moet steeds in een geëncrypteerde vorm verschijnen, nooit in leesbare text.


9

VMM-infrastructuur

Versie: 3.01

Het Team systeembeheer verwacht duidelijke afspraken over hoe en door wie de security-updates van de toepassing uitgevoerd worden. We denken hier dan aan gekende security-problemen in bv. apache en dergelijke waarvoor er reeds een patch/upgrade bestaat. Ook het testen van de updates is een taak voor de leverancier van de toepassing. Het Team systeembeheer staat in voor de security-updates van het besturingssysteem, tenzij dit op voorhand afgesproken wordt. Het Team systeembeheer verwacht gedetailleerde informatie over hoe backup’s en restores uitgevoerd dienen te worden. Alle communicatiestromen tussen netwerken beheerd door het Team systeembeheer en externe netwerken mag uitsluitend gebeuren over een PEP (policy enforcement point) beheerd door het Team systeembeheer. Met een PEP wordt een fysiek toestel zoals firewall, forward/reverse proxy, SSL-VPN en dergelijke bedoeld. Deze PEP’s, alsmede andere (netwerk)infrastructuur, mogen zich uitsluitend bevinden in afgesloten lokalen of serverkasten, opdat enkel VMM-IT-personeel zich hiertoe toegang kan verschaffen. Indien externe ondersteuning voorzien wordt, dient deze te beschikken over een toegankelijke SPOC (single point of contact). Gelieve systeembeheer te contacteren mochten bepaalde zaken hieromtrent niet duidelijk zijn. 5.5 Schermovername door externen Tools die door externe partijen gebruikt worden voor schermovername dienen eveneens te voldoen aan bovenstaande regels meer bepaald NTLM-authenticatie via de proxy en enkel gebruik van poorten tcp_80 en tcp_443 (bij voorkeur).


10

VMM-infrastructuur Versie: Situering... 1

Recommend Documents