Tilgang til tredjepartssystemer

Innledning

Dette dokumentet beskriver hvilket tilgangsnivå Identum krever til kundesystemer under og etter en prosjektgjennomføring. Vår policy er å bruke midlertidig tilgang med minst mulig privilegier for å fullføre de nødvendige oppgavene. Identum krever ikke permanent tilgang til kundemiljøer.

1. Kildesystemer

Identum trenger ikke permanent brukertilgang til kildesystemer som HRM/lønn, studentinformasjonssystemer eller andre personaldatabaser. Tilgang til dataeksport fra disse systemene, enten via filoverføring eller API, er tilstrekkelig.

Merk: På forespørsel kan vi kreve midlertidig tilgang for spesifikke oppgaver som feilsøking eller opplæring.

2. Dataporten / Feide Customer Portal

Vi krever ikke permanent tilgang til Dataporten eller Sikts (tidligere Uninett) kundeportal. Midlertidig tilgang kan gis på forespørsel ved behov.

3. Microsoft Azure Active Directory (Azure AD)

Hvis våre tjenestereADMeFeideeADM skal synkronisere brukere, grupper, passord, lisenser, medlemskap og status til Azure AD, trenger vi en konto med rettigheter tilsvarende Brukeradministrator i Microsoft 365.

• Denne tilgangen er kun nødvendig så lenge prosjektet varer.

• Kontoen må være beskyttet med multifaktorautentisering (MFA).

• Kontoen må deaktiveres eller fjernes når prosjektet er fullført.

Merk: Den løpende kommunikasjonen mellom eFeide og Azure AD administreres via en Azure Enterprise Application, ikke en brukerkonto. For konfigurasjonsdetaljer, se vår dokumentasjon: Slik konfigurerer du Azure AD for integrasjon.

4. Google Workspace

Hvis tjenestene våre skal synkronisere brukere, grupper, passord, organisasjonsenheter (OU-er), medlemskap og status til Google Workspace, trenger vi en brukerkonto med rettigheter tilsvarende User Management Admin.

• Denne kontoen må være beskyttet med MFA.

• Kontoen kan deaktiveres når prosjektet er fullført.

I tillegg må kundens globale administrator konfigurere tilgangsnøkler for API-klienten vår.

5. Lokal Active Directory (AD)

For lokal AD-integrasjon installeres en klientapplikasjon på kundens interne nettverk. eADM krever ikke en dedikert server. Vi anbefaler ikke å installere eADM på en domenekontroller.

Kundekommunikasjon

• Klienten er en Windows-basert .NET-konsollapplikasjon som kjører som en planlagt oppgave ved hjelp av en tjenestekonto.

• Kommunikasjonen med vår skyløsning initieres av klienten via en kryptert forbindelse (TLS 1.2 på port 443 utgående). Ingen inngående brannmuråpninger er nødvendige.

• Hver klient bruker unike autentiseringsnøkler for å kommunisere med skytjenesten.

Konsulenttilgang (under prosjektet)

I løpet av prosjektet vil prosjektlederen og/eller konsulenten ha behov for ekstern tilgang til det lokale AD-miljøet via VPN eller TeamViewer.

• Denne tilgangen må beskyttes med MFA.

• Tilgang kan være til en primær domenekontroller, men vi anbefaler å bruke en dedikert server for eADM .

• Serveren må ha tilgang til:

  • Active Directory-brukere og -datamaskiner

  • Active Directory-modul for Windows PowerShell

  • Windows Exchange Management Tools for PowerShell (hvis aktuelt)

Krav til server

• Operativsystem: Windows Server

• .NET Framework: Versjon 4.0 eller nyere

• PowerShell: Versjon 4.0 eller nyere

• Brannmur: Port 443 må være åpen for utgående SSL-trafikk.

• Programvare: Sørg for at Notepad++ er installert på serveren.

Tillatelser for tjenestekontoer

Det kreves en dedikert tjenestekonto for å kjøre eADM . Denne kontoen trenger følgende tillatelser:

• AD-rettigheter: Opprette, slette og endre brukere, grupper og organisasjonsenheter.

• Lokale rettigheter:

  • Logg på som en batchjobb (for planlagte oppgaver).

  • Full lese-/skriveadgang til C:eADM og dens undermapper.

• Valgfrie rettigheter (hvis aktuelt):

  • Opprett og angi NTFS-tillatelser for brukerens hjemmemapper.

  • Opprett postkasser (aktivere postkasse og aktiver-remotepostkasse).

Advarsel: Når systemet er satt i produksjon, må våre personlige brukerkontoer deaktiveres. Alle driftsoppgaver vil bli utført av servicekontoen, og passordet bør endres slik at Identum ikke lenger har tilgang til den.

Sammendrag for AI og søk

Denne standardprosedyren (SOP) definerer hvilke tilgangstillatelser Identum krever for kundens tredjepartssystemer, som Azure AD, Google Workspace og lokale Active Directory. Det understrekes at tilgangen er midlertidig, begrenset til prosjektperioden og følger prinsippet om minst mulig privilegier. Dokumentet beskriver kravene til tjenestekontoer, konsulenttilgang, serverkonfigurasjon og sikkerhetsprotokoller, inkludert obligatorisk bruk av MFA og deaktivering av kontoer etter prosjektslutt.