Bilag 2 Kundens it-miljø

Bilag 2 Kundens it-miljø

1. Vejledning til tilbudsgiver I bilaget er relevante dele af Kundens it-miljø beskrevet. Kunden står generelt selv for drift af it-miljø, ligesom kunden forventer at drifte en fremtidig IdM løsning selv. Der er enkelte services/applikationer, der køres eksternt. Tilbudsgiver skal i afsnit 4 i nærværende bilag specificere de krav, der stilles til Kundens it-miljø såvel under konfigurations- og implementeringsforløbet som i vedligeholdelsesperioden. Tilbudsgiver skal angive de krav til dimensionering, der er nødvendige for at opfylde de i bilag 6 beskrevne servicemål. Tilbudsgiver bedes endvidere anføre eventuelle yderligere krav til it-infrastrukturen. 2. Det eksisterende it-miljø I nærværende afsnit har Kunden beskrevet sit eksisterende IT-miljø, som det forefindes på nuværende tidspunkt. Kunden står selv for it-drift og varetager således ansvaret for infrastruktur og servere til og med operativsystem og middleware. Specialudviklede services vedligeholdes dog af udviklingsleverandører. AAU bruger 2 fysiske datacentre, som er placeret på forskellige adresser. Disse huser de fysiske og virtuelle servere. Datacentrene er opbygget efter stretched data center princippet, og kan logisk betragtes som ét datacenter. High availability (HA) tjenester leveres ofte fra begge data centre. Backup data og servere som foretager backup er placeret i separate rum. 2.1. Overordnet it-arkitektur og strategi herfor Kunden har defineret 6 bærende it-strategiske principper: 1. Den samme arbejdsopgave skal løses ved samme arbejdsproces med samme it-løsning. 2. Data registreres ved kilden, dvs. der, hvor data naturligt fødes, opdateres ét sted og anvendes mange steder. 1

3. Procesejeren har ansvaret for digitalisering af hele arbejdsprocessen og har ansvaret for, at digitaliseringen gennemføres med involvering af alle interessenter. 4. Digitalisering sker om muligt ved anvendelse af nationalt definerede itløsninger (fællesoffentlige løsninger), dernæst ved brancheløsninger (universitære fællesløsninger), dernæst etablerede standardløsninger, som kan købes færdige og slutteligt gennem egen udvikling på AAU. AAU udvikler samtidig helst it-services i fællesskab med andre universiteter. 5. Valg af it-løsninger sker med udgangspunkt i offentlige standarder og offentlige arkitekturprincipper. 6. Ved anskaffelse og udvikling af nye it-systemer skal der altid ske vurdering af både open source og kommercielle teknologier. Ovenstående principper kan naturligvis fraviges, hvis det skaber værdi for AAU at gøre det, og det samtidig kan forklares, hvorfor der afviges, samt at der er taget højde for konsekvenserne ved afvigelsen. Uddybning af principperne er vedlagt som bilag 2A. 2.2. Arkitektur AAU benytter en række principper, som påvirker arkitektoniske beslutninger. Der gøres opmærksom på, at AAU arbejder hen i mod nedenstående principper, men at de fleste systemer i dag ikke opfylder alle principperne. 1. Microsoft Active Directory (AD) er AAU s foretrukne måde at styre brugerkonti og rettigheder på i målsystemer, såfremt målsystemerne understøtter AD integration. 2. Authentication til udvalgte services skal benytte two factor authentication (2FA). 3. Single Sign On skal benyttes for adgang til udvalgte systemer/services. 4. AAU benytter 3 tier netværkssikkerheds zone arkitektur (se figur 6) med fokus på datasikkerhed. Dette betyder, at data afgør, i hvilken zone systemet skal placeres. Det anbefales, at databaser benyttet af systemet implementeres på separate servere i forhold til applikationen. Det anbefales, at AAU s database produktionsmiljø benyttes, såfremt systemet understøtter det, i stedet for egne dedikerede database løsninger. 5. AAU adskiller test/udviklingsmiljø fra produktionsmiljø for enkelte systemer. Disse miljøer benytter oftest forskellige roller. Set fra et IDM synspunkt er det separate systemer. 6. AAU ønsker på sigt, at data udstilles gennem datafordeler i stedet point to point udstillings processer. Datafordeler eksisterer ikke i dag. 2

Figur 1. Oversigtstegning over IDM og målsystem integrationer. 7. AAU ønsker at konfigurationer af målsystemer, såsom oprettelse af nye brugere/ressourcer, laves gennem orchestratorer og ikke som direkte transaktioner gennem IDM systemet og målsystemerne (se figur 1 system A og system B). Figur 1 er AAU s vision for, hvordan IDM systemet integreres med eksisterende systemer. AAU forventer, at der i projektet udarbejdes de nødvendige orchestrator runbooks til integrationen med de forskellige målsystemer. For udvalgte systemer (system C) kan direkte transaktioner mellem IDM og målsystemerne i særlige tilfælde tillades. 2.3. Nuværende håndtering af identiteter og rettigheder på AAU AAU anvender i dag både systemer med lokale identiteter og roller, og systemer som henter identiteter og roller fra andre systemer såsom Microsoft Active Directory (AD). I øjeblikket er AAU AD implementeret som single skov (forrest), multiple domæne. Der er aftalt et bærende princip om, at alle nye systemer skal kunne integrere op imod AD i forhold til autentificering og gerne også autorisation. AD benyttes til at styre brugers adgang til en lang række grundlæggende services på AAU så som mail, kalender, intranet, Wi-Fi, print, VPN, Fileservice (Fileshare), SharePoint, Office 365, Skype for Business mv. Lokale identiteter på nogle systemer synkroniseres mod AD. AAU benytter Single Sign On (autentificering mod AD) for at styre adgang til visse ressourcer/systemer. 3

AAU har et egenudviklet IdM-system (ADMdb/eduser), som styrer oprettelse af brugere og nogle ressourcer, såsom mail-boks og kalender i AD. På sigt skal det nye IdM system erstatte den nuværende løsning. Løsningen er kendetegnet ved en række integrationer, som i et vist omfang skal videreføres. For så vidt angår de dele, der ønskes videreført, henvises til bilag 3, Kravspecifikation. STAP (STADS) AAUP (STADS) Basis ADM STAP (Unistart) Region Nordjylland Web Service Equitrac printer accounting MS multidomain Active Directory Forest SyncAgent Stads SyncAgent Basis ADMdb Web Service ITS support E-mail to receipients AAUP (PAU) SyncAgent AAUCard ADMdb students ADMdb Employees Guests Workgroup Projectgroup Office Phone Eduser Agent EduserDb Windows Web Service (Agents) Fileshares PDS Web Service Web server SyncAgent PDS SyncAgent SCANPAS SCANPAS SyncAgent NummerPlan Telephone Nummerplan FællesService Agent Real SCANPAS Domain Ctrls (User mgmt Group mgmt Attributes) Exchange MailBox Calendar Distributions Lists Forwarding for DCM 2016.08.16 v1.3 Figur 2. Oversigtstegning over ADMDB/eduser integrationer. 1. STAP og AAUP (STADS). Der hentes identiteter og studieoplysninger for de studerende i STADS (master data). Efter oprettelse af brugerkonto + mail i AD/Exchange uploades mail adresse til STADS. 2. SCANPAS og Real SCANPAS. Der hentes tjenestesteder, medarbejder nr. og CPR fra SCANPAS og Real SCANPAS, og data opdateres i ADMDB /AD. Mail distributions lister i AD/Exchange opdateres på baggrund af tjenestesteder. 3. PDS. 4

Der hentes billeder af de ansatte i PDS, og billederne uploades til AD. 4. NummerPlan (telefonnumre til de ansatte). Der hentes regneark med telefon nummerplan og telefonnumre NummerPlan og data opdateres i ADMDB/AD. 5. AAUP (PAU) - AAU adgangskort oplysninger. Der hentes oplysninger om adgangskort for de ansatte og studerende i AAUP (PAU) og data opdateres i ADMDB og EQUITRAC. 6. EQUITRAC - AAU printer accounting system. Der hentes oplysninger om adgangskort for de ansatte og studerende i AAUP (PAU) og data opdateres i ADMDB og EQUITRAC. For nye studerende uploades et antal gratis print units. 7. BASIS ADM system brugt af Basis-uddannelse-administration til bland andet oprettelse af grupper af studerende. Synkronisering mellem Basis ADM og ADMdb. Oprettelse af grupper i AD, mail distributionslister i Exchange og gruppe fileshares i Fileservice. 8. Region Nordjylland Web Service e-mail adresser for DCM institut (klinisk institut) hentes. E-mail forwarding og kalender synkronisering etableres. 2.4. Servere og operativsystemer I øjeblikket benytter AAU: Dell, HP og Cisco UCS rack servere. Servere installeres med Windows eller Linux operative systemer. Servere placeres i AAU s egne datacentre. AAU benytter VMware (ESX 6.0) til virtualisering. Nye systemer, hvis der ikke findes grund til andet, implementeres på virtuelle platforme. 2.5. Arbejdsstation (klienter) Medarbejdernes arbejdsstation består typisk af PC (ofte bærbar) med Windows, MacOS (OS X) eller Linux OS. Der findes Remote Desktop, Linux applikations servere, som kan benyttes for adgang til systemer med særlige krav til klient software. Der forventes jævnligt og efter behov opdatering af klient software (især OS) med de nyeste versioner og patches. 2.6. Anvendte softwareversioner Benyttede af AAU software versioner (udvalgte): 5

System Beskrivelse OS server (anbefalet) Ubuntu Linux (64 bit) LTS 16.0.4 (14.0.4) OS server (anbefalet) RedHat Enterprise Linux (64 bit) 7.0.0 OS server (anbefalet) Microsoft Windows Server 2012 (64 bit) OS klient Microsoft Windows 10 OS klient Microsoft Windows 7 OS klient MacOS - forskellige OS klient Linux - forskellige OS tablet klient Windows 10, Mac ios forskellige, Android forskellige Active Directory Microsoft Windows Server 2012 (64 bit) OS Oracle server Oracle Linux 4/5/6/7 (64-bit) Oracle DB flere systemer Oracle Database 11g Enterprise Edition Release 11.2.0.x.0-64bit Production Oracle ebusiness Suite Version 12.13 AAU har et veletableret produktionsmiljø for flere typer databaser (herunder MS SQL, Oracle, PostgresSQL, ). 6

2.7. Netværk Netværk på AAU er bygget efter et struktureret design princip, hvor moduler har velbeskrevne funktioner. Udvalgte views på AAU netværk er beskrevet herunder. Internet Edge modul External partner network Data center Core modul Service moduls Service modul Distribution modul Distribution modul Distribution modul Access modul Access modul Access modul Figur 3: Netværksoversigt - moduler. Servere (systemer) er normalt tilsluttet netværk gennem Data center modul. Klienter (PC, tablets, etc), som tilgår systemer, er koblet gennem Access modulerer. 7

OSI layer 3 (routing) Distribution modul OSI layer 2 (switching) Access modul PoE+ switch WiFi AP WiFI AP Lab server Laptop Figur 4: Kobling af klienter til netværk. 8

Internet Edge modul External partner network Data center Core modul Wifi controllers (Service moduls) Service modul Distribution modul Distribution modul Distribution modul Access modul Access modul Access modul Figur 5: Forsvars principper firewalls/filters markeret med rød. Firewalls and filters er benyttet i følgende moduler: edge, data center, distribution og Wi-Fi controllers service modul. AAU benytter 3 tier netværkssikkerheds zone arkitektur (se figur 6) med fokus på datasikkerhed. Hver sikkerhedszone (ring) kan bestå af flere netværk (IP sekvenser). IP adresser for servere og services hører til konkrete netværk (IP sekvens) og sikkerheds zoner. Et netværk (IP sekvens) kan kun være i en sikkerhedszone. Indre zoner beskyttes af ydre zoner (løg princip). Data flow mellem zonerne begrænses til tilstødende zoner. Alle data kategoriseres. Applikation og Data zonen skal huse data, som forretningen ønsker at beskytte mod direkte adgang fra Internet. Hemmelig eller fortrolige data skal være i Data zonen. Demilitarized zone (DMZ) består af et antal netværk i sikkerhedszone Ring2 (Presentation). 9

Internet Ring2 (Presentation) Ring1 (Application) Ring0 (Data) Illegal transfer Permitted transfer Figur 6: Forsvars principper 3 tier (zone) netværks segmenterings model. 2.8. It-systemer, som leverancen skal integrere til Henvises til kravspecifikationen og fakta ark (bilag 2B). 2.9. Relevante it-miljøer AAU benytter følgende IT-miljøer: udvikling, test, præproduktion og produktion (se figur 7). Leverancen skal installeres i mindst to instanser: én i testmiljøet og én i produktionsmiljøet. Der kan opstå et behov for installering af separate instanser for flere miljøer såsom præproduktionsmiljøet eller udviklingsmiljøet. Udviklingsmiljø I dette miljø udvikles systemer og applikationer af udviklere. Brugere er normalt ikke involveret. Der må ikke i dette miljø findes data, der er omfattet af sikkerhedsbestemmelserne, hvilket indebærer, at alle testdata skal være konstruerede eller anonymiserede produktionsdata. Testmiljø 10

I dette miljø testes systemer og applikationer af brugere i tæt samarbejde med udviklere. Systemer skal overholde navnekonventioner, rettigheder mv. som angivet i denne vejledning. Brugere kan oprettes efter behov og tildeles roller og rettigheder i applikationer i den udstrækning, testen kræver det. Der må ikke i dette miljø findes data, som er omfattet af sikkerhedsbestemmelserne, hvilket indebærer, at alle testdata skal være konstruerede eller anonymiserede produktionsdata. Præproduktionsmiljø Dette er sidste testmiljø under produktionslignende forhold primært for driftsafdelingen. Systemer skal være gennemtestet og godkendt til produktion. Udvalgte brugere kan få adgang til systemet med henblik på sidste test. Data er enten produktionsdata eller kopi af disse. Adgang til data, logfiler mv. kun til udvalgte, særligt autoriserede personer. Produktionsmiljø Dette er essentielt produktionsmiljøet, som det kendes i dag med levende data. Udviklere og supportfolk tildeles kun adgang til de enkelte systemer og ikke platformen generelt. Denne adgang skal kun give ret til at se data, logfiler mv. til udvalgte, særligt autoriserede personer. 11

Test Produktion Udvikling Præproduktion Anonymiserede data Produktionsdata Figur 7: IT-miljøer. 2.10. Særlige it-systemer til understøttelse af udvikling Udvikling af integrationskomponenter kan understøttes af forskellige systemer. Eventuelt valg af særlige systemer efter nærmere aftale. 2.11. Koncept for it-sikkerhed ISO 27001 standarden anvendes. Netværkssegmentering ifølge ringmodellen (se figur 6). Fortrolige data skal placeres i ring0. High Availability (HA) for kritiske IT services. Audit data for ændringer og login, herunder forsøg på login. Skal gemmes i længere periode (skal afklares i forbindelse med arklaringsfasen). Fortrolige data, såvel lokal opbevaret som i transit, skal krypteres. 2.12. Relevante driftsarbejdsgange Support center (e-mail: support@its.aau.dk, telefon: +45 9940 2020) åbningstider 08.00-15.30 fra mandag til torsdag og 08.00-15.00 fredag. For mere informationer se http://www.its.aau.dk/support/. 12

Det forventes, at relevante punkter fra Modtagelseserklæring (se Bilag 7A) udfyldes af leverandøren, før systemet kan tages i brug. Systemet ønskes overvåget. AAU anvender Microsofts SCOM og Icinga. Backup Der foretages backup mindst en gang om dagen og backups gemmes som udgangspunkt 14 dage for servere. Der er mulighed for hyppigere backup og for at gemme data i længere tid, hvis det skulle være nødvendigt. Veeam Backup benyttes for alle virtuelle servere, mens Microsoft DPM benyttes til Windows servere og services og Bacula bruges til Linux servere. 2.13. Faciliteter til leverandørens rådighed Fjernadgang til systemet. Undervisningslokaler med video faciliteter (reservation påkrævet). Fysisk arbejdsplads på AAU efter nærmere aftale. 3. Leverandørens krav til miljøer [Her anføres leverandørens krav til opsætning af miljøer] 13