Innhold
1 Status
Dato | Status |
---|---|
2014-09-23 | Utkast sendt ut internt for høyring |
2014-10-22 | Sterkt forsinka, men oppdatert med endringar for sperring, etter tilbakemeldingar frå Cerebrum drift |
2014-10-29 | Oppdatert plan med framdrift etter statusmøte |
2016-12-08 | Oppdatert dokument etter oppdateringar siste åra, for sluttrapport |
2 Motivasjon
EIR-rapporten frå 2013 viste eit behov for bedring av rutinene for fjerning av IT-tilgangar frå personar ved UiO. For Cerebrum er ønsket å:
- Automatisk sperre IT-tilgangen til alle personar som ikkje (lenger) har aktiv tilknytting til UiO.
- Automatisk rydde heimeområder og anna til sperra, inaktive brukarar.
- Automatisk fjerne utvida IT-tilgangar til personar utan aktiv tilknytting til UiO.
- Automatisk fjerne utvida IT-tilgangar til personar som bytter arbeidsstad internt på UiO. Dette for å ikkje beholde gamle tilgangar på gamal enhet.
3 Interessentar
- IT-sikkerhetssjef. Held aktiviteten.
- Lokal IT (lk-alle@usit.uio.no), då det er deira brukarar som evt. vil bli sperra.
- Avdeling for Administrativ Støtte (ADS), som er ansvarleg for SAPUiO. Adresser: ads-ledere@admin.uio.no.
- Avdeling for Fagstøtte (AF), som eig FS-data. Adresser: info-ko@admin.uio.no og fs-adm@admin.uio.no.
- UNIX-drift på USIT, då det vil bli endringar på infrastrukturen, spesielt heimeområder.
4 Løysing
Vi deler opp løysingsforslag etter punkta frå Motivasjon. Løysingsforslaget er generelt, så den vil påvirke både tilsette, studentar, gjestar og andre.
4.1 Sperring
Vi innfører ei rutine som sperrer alle brukarkontoane til personar utan aktive tilknyttingar. Rutina varsler personen ei stund i forvegen, og sperrer ved å sette kvar brukar i karantene. Sjå Automatisk sperring av brukarar utan gyldig persontilknytting for meir informasjon om rutina.
Kva som må gjerast:
- Avklaringar:
- Kva må utviklast?
- Konfigurasjon og andre innstillingar.
- Når skal rutina køyre?
- Informasjon må oppdaterast:
- Spesifikasjonar av rutina: Automatisk sperring av brukarar utan gyldig persontilknytting
- Spesifikasjon av oppsettet for UiO.
- For sluttbrukarane som vert truffe: Jeg har fått beskjed om at brukerkontoen min skal sperres
- For lokal IT: tjenester/it/
- For Student-IT: Studentautomatikk
- Rapportering for lokal IT: Liste over kven som står i fare for å bli sperra
- Varsle på e-post til Interessentar.
Rutina vert innført i fasar:
Sperr først alle som har ingen tilknyttingar.
Inkluder personar med manuelle tilknyttingar.
Denne fasen krever at vi også sperrer muligheten for at lokal IT kan registrere visse tilknyttingstypar. Unntaket er randsoner, som vi må registrere manuelt i Cerebrum. Dette krever utvikling, sjå CRB-582.
Dato | Kva | Ansvarleg | Status |
---|---|---|---|
2014-09-01 | Sjå til at all funksjonalitet er på plass | Utvikling | Fullført |
2014-09-01 | Oppdater infosider | jokim | Fullført |
2014-09-01 | Oppdater spec av oppsett | Drift | Delvis fullført |
2014-09-01 | Informer interessentar | espegro | Fullført |
2014-09-08 | Start rutine, fase 1 | Drift | Fullført 9. sept |
2016-09-30 | Start rutine, fase 2, etter avklaring med LKIT | tvl | 2016-09-08 |
2016-10-15 | Slett gamle affiliations | tvl | |
2016-10-15 | Lag sluttrapport for aktiviteten | jokim | 2016-12-08 |
4.2 Avvikling
Vi innfører ei rutine som skal sende alle brukarar som har vore i karantene i ein periode til avvikling. Behov vi har for skriptet:
- Utplukk: Alle brukarkontoar som har hatt ei gitt karantene i meir enn eit gitt antal dagar.
- Alle personar som har ei aktiv person-tilknytting må kunne ignorerast frå å bli avvikla. Dette er for å til dømes unngå å avvikle kontoar til ansatte som ikkje har bytta passord på ei god stund, då dei sjeldan har bruk for IT-tilgang. Skriptet bør kunne sjå på eit utplukk av tilknyttingstypar, sidan visse manuelle tilknyttingar bør kunne ignorerast.
- Det må kunne begrensast kor mange kontoar vi avvikler samtidig. Dette då arkiveringsløysinga har begrensa kapasitet, og mange brukaravviklingar i kø vil hindre normal drift.
- For UiO vil skriptet måtte bruke BofhdRequests for å avvikle brukaren, men for enkelte andre instansar vil ein måtte kunne sette expire_date og anna direkte, til dømes gjennom Account.deactivate().
- Brukarar som eigast av grupper må behandlast spesielt.
- Skriptet må vere dokumentert, på samme måte som anna automatikk i Cerebrum.
Kva som må gjerast:
Avklaringar:
Er funksjonaliteten som finnast god nok? Dersom det trengs utvikling vil vi måtte utsette å starte rutina, då det er ikkje utviklingskapasitet på ei stund.
Svar: Manglande funksjonalitet vart implementert i CRB-365_.
Konfigurasjon og andre innstillingar. TODO: Lenke til spec for oppsett. (ikke helt utarbeidet ennå, men kan dette ikke under Jobben for å avvikle brukere som har vert i karantene for en stund være et godt startpunkt?).
Kva karantenetypar skal rutina sjå på?
Svar: I første omgang tek vi `auto_no_aff`. Neste runde går over `autopassord` og `auto_inaktiv`.
Vi må vurdere å ta ein ekstra runde og gå over generell, slutta og svakt_passord.
Kva manuelle person-tilknyttingar kan ignorerast, så kontoar vert sperra sjølv om personen har ei manuell tilknytting?
LKIT bruker i dag tilknyttingstypane, som vi ikkje kan sperre:
- MANUELL/cicero
- MANUELL/ekst_person
- MANUELL/gjest
- MANUELL/gjesteforsker
- MANUELL/inaktiv_ansatt
- MANUELL/inaktiv_student
- MANUELL/konsulent
- MANUELL/radium
- MANUELL/unirand
- MANUELL/universitas
- TILKNYTTET/ekst_partner
- TILKNYTTET/isf
Svar: Vi begynner med å berre ignorere `UPERSONLIG`.
Vi legg til ei oppgave på å rydde opp og slette gamle, ubrukte tilknyttingstypar, CRBD-107. Vi legg også til ei sperre så ingen andre enn LKIT har tilgang til å legge til manuelle tilknyttingar, CRB-582.
Merk: Vi kan ikkje starte avviklinga av dei med manuelle tilknyttingar heilt endå. Vi må difor utsette dette til neste år.
Kor mange avviklingar kan vi støtte i døgnet? Å sende heimeområder til backup vil ta litt tid, og om det er ei stor kø i BofhdRequest vil dette kunne påvirke normal drift, ved at lokal IT ikkje får flytta andre brukarar sine heimeområder, eller oppretta brukarkontoar sine heimeområder.
Det ser ut til at det er berre kapasitet til å avvikle 200 brukarar per døgn, då det tek tid å få arkivert store heimeområder.
Skriptet må bli testa før det kan gå i produksjon, så vi er sikre på at vi treff dei riktige brukarane.
Dette gjerast av Cerebrum drift.
Informasjon må oppdaterast:
Spesifikasjonar av rutina: Fullført: Automatisk avvikling av brukarar
Spesifikasjon av oppsettet for UiO: TODO: blant disse spesifikasjonene så var det diskutert på fredag internt møtet at gd-gsd gruppen trenger kanskje en daglig oversikt av hvilke brukere det kommer til å avvikles per døgn gitt at vi ikke kommer til å avvikle flere enn 200 brukere per døgn i begynnelsen, estephaz har avtalt med trondham at en enkel rapport kan sendes daglig til it-drift-gd-gsd@usit.uio.no (kopi cerebrum-drift) med listen over enkelte brukere som kommer til å avvikles.
For lokal IT: Avvikling av brukarar. Status: Oppdatert
For Student-IT: Studentautomatikk. Status: Oppdatert
Rapportering for lokal IT: TODO: Kva trengs? Er det nok med ei lang liste over alle brukarnamn, eller må vi sortere den på noko vis?
Vi diskuterte, og vi bør ha mulighet til å gje brukarar ei liste over brukarnamn, sortert på disk. Dette er ønskeleg av lokal IT. Vi er riktignok ikkje sikre på om dette er den beste måten å vise fram informasjonen, men det er mange forskjellige behov hos lokal-IT.
Varsle på e-post til dei dette er relevant for, som her er unix-drift, som drifter lagringsløysinga, og lk-alle, som har ansvar for diskane brukarane ligg på.
Rutina kan innførast gradvis, ved å bestemme kva karantenetypar den skal sjå på. Karantena auto_no_aff er den viktigaste, men det er ønskeleg å også avvikle personar som har hatt autopassord i ein lang periode, utan å ha noko persontilknytting.
Dato | Kva | Kven | Status |
---|---|---|---|
2014-10-22 | Sjå til at all funksjonalitet er på plass, eller om vi treng utvikling. Utviklingsbehov gjer at tidsplanen vert forskjøve. | Utvikling | Fullført |
2014-10-24 | Få på plass avklaringar | jokim | Fullført |
2014-10-24 | Finn muligheter for rapportering av brukarar per disk. | jokim | Fullført |
2014-10-24 | Oppdater/lag alle påkrevde infosider | jokim | Fullført |
2014-10-28 | Snakk med unix-drift om arkivering | estephaz | Fullført |
2014-10-28 | Oppdater spec av oppsett | Drift | |
2014-10-28 | Oppdater infosider | Drift | |
2014-10-29 | Legg ut rapporter, med liste over pårørte brukarkontoar. Rapporteringa må settast opp til å køyre kvar dag. | Drift | |
2014-10-29 | Informer interessentar | Drift | |
2014-11-05 | Start rutine for første karantenetypen. Informer interessentar om at dette no køyrer kvar dag. | Drift | |
2014-11-10 | Start rutine for fleire karantenetypar | Drift | |
2014-12-01 | Rutina køyrer for alle karantenetypar som er bestemde | Drift | |
Utvid avviklinga til å inkludere manuelle person-tilknyttingar. Treng avklaringar. | Utsatt |
4.3 Gruppeutmelding
Vi kan innføre ei rutine som ser på alle brukarkontoar utan persontilknyttingar, og fjerner (dei fleste) gruppemedlemskap. Dette har vi ikkje funksjonalitet for per i dag.
Informasjon som må oppdaterast:
- Spesifikasjonar av rutina: TODO
- Spesifikasjon av oppsettet for UiO: TODO
- For sluttbrukarane som vert truffe: TODO
- For lokal IT: TODO
- For Student-IT: TODO
- Rapportering for lokal IT: TODO: Kva trengs?
Dato | Kva | Kven | Status |
---|---|---|---|
2014-10-10 | Få avklart og definert kva som trengs av funksjonalitet | jokim | |
TODO | Utvikle rutina. Rutina må vere generell nok til å kunne brukast av alle instansar, og den må dokumenterast, sjølv om funksjonaliteten evt. skulle leggast direkte i API-et. | Utvikling | |
TODO | Oppdater alle påkrevde infosider. | ||
TODO | Få avklart at rutina kan innførast, og når | jokim | |
TODO | Varsle interessentar om rutina | jokim | |
TODO | Start rutina | Drift |
4.4 Gruppeutmelding ved bytte av enhet
Vi har ikkje kunne støtte gruppeutmelding ved bytte av enhet internt på universitetet. Dette kjem av at vi ikkje har noko datagrunnlag for dette, vi har ikkje noko knytting mellom grupper og enhetar. Det vi kan gjere, er å anbefale lokal IT å ta i bruk enhetsgruppene i større grad, altså grupper på formatet ansatt-123456, for tilgangar - desse gruppene vert automatisk vedlikeholdt etter kva tilknyttingar personar har.