Tillgång till system från tredje part

Inledning

Detta dokument beskriver den åtkomstnivå som Identum kräver till kundsystem under och efter en projektimplementering. Vår policy är att använda tillfällig åtkomst med lägsta möjliga behörighet för att utföra de uppgifter som krävs. Identum kräver inte permanent åtkomst till kundmiljöer.

1. Källsystem

Identum behöver inte ha permanent användaråtkomst till källsystem som HRM/löneadministration, studentinformationssystem eller andra personaldatabaser. Det räcker med tillgång till dataexport från dessa system, antingen via filöverföring eller API.

Obs: På begäran kan vi kräva tillfällig åtkomst för specifika uppgifter som felsökning eller utbildning.

2. Dataporten / Feide Kundportal

Vi kräver inte permanent tillgång till Dataporten eller Sikts (tidigare Uninett) kundportal. Tillfällig åtkomst kan beviljas på begäran om det behövs.

3. Microsoft Azure Active Directory (Azure AD)

Om våra tjänster (eADM/eFeide) ska synkronisera användare, grupper, lösenord, licenser, medlemskap och status till Azure AD behöver vi ett konto med behörigheter motsvarande Användaradministratör i Microsoft 365.

• Denna åtkomst är endast nödvändig under projektets gång.

• Kontot måste vara skyddat med multifaktorautentisering (MFA).

• Kontot måste inaktiveras eller tas bort när projektet är slutfört.

Notera: Den pågående kommunikationen mellan eADM/eFeide och Azure AD hanteras via en Azure Enterprise Application, inte ett användarkonto. För konfigurationsdetaljer, se vår dokumentation: Hur man konfigurerar Azure AD för integration.

4. Google Arbetsyta

Om våra tjänster ska synkronisera användare, grupper, lösenord, organisationsenheter (OU), medlemskap och status till Google Workspace behöver vi ett användarkonto med behörigheter motsvarande User Management Admin.

• Detta konto måste skyddas med MFA.

• Kontot kan inaktiveras när projektet är slutfört.

Dessutom måste kundens globala administratör konfigurera åtkomstnycklar för vår API-klient.

5. Lokalt Active Directory (AD)

För lokal AD-integration installeras en klientapplikation i kundens interna nätverk. eADM kräver inte en dedikerad server. Vi rekommenderar inte att eADM-klientapplikationen installeras på en domänkontrollant.

Kommunikation med kunder

• Klienten är ett Windows-baserat .NET-konsolprogram som körs som en schemalagd aktivitet med hjälp av ett servicekonto.

• Kommunikationen med vår molnlösning initieras av klienten via en krypterad anslutning (TLS 1.2 på port 443 utgående). Inga inkommande brandväggsöppningar är nödvändiga.

• Varje klient använder unika autentiseringsnycklar för att kommunicera med molntjänsten.

Tillgång till konsulter (under projektet)

Under projektet kommer projektledaren och/eller konsulten att behöva fjärråtkomst till den lokala AD-miljön via VPN eller TeamViewer.

• Denna åtkomst måste skyddas med MFA.

• Åtkomst kan ske till en primär domänkontrollant, men vi rekommenderar att du använder en dedikerad server för eADM-klienten.

• Servern måste ha tillgång till:

  • Active Directory-användare och -datorer

  • Active Directory-modul för Windows PowerShell

  • Windows Exchange Management Tools för PowerShell (om tillämpligt)

Krav för server

• Operativsystem: Windows Server

• .NET Framework: Version 4.0 eller nyare

• PowerShell: Version 4.0 eller nyare

• Brandvägg: Port 443 måste vara öppen för utgående SSL-trafik.

• Programvara: Se till att Notepad++ är installerat på servern.

Behörigheter för servicekonto

Ett särskilt servicekonto krävs för att köra eADM-klienten. Det här kontot behöver följande behörigheter:

• AD-rättigheter: Skapa, ta bort och ändra användare, grupper och organisationsenheter.

• Lokala rättigheter:

  • Logga in som ett batch-jobb (för schemalagda uppgifter).

  • Fullständig läs- och skrivåtkomst till C:\eADM\ och dess undermappar.

• Valfria rättigheter (om tillämpligt):

  • Skapa och ställ in NTFS-behörigheter för användares hemmappar.

  • Skapa brevlådor (enable-mailbox och enable-remotemailbox).

Varning! När systemet är i produktion måste våra personliga användarkonton inaktiveras. Alla operativa uppgifter kommer att utföras av servicekontot, och dess lösenord bör ändras så att Identum inte längre har tillgång till det.

Sammanfattning för AI och sök

Denna Standard Operating Procedure (SOP) definierar de åtkomstbehörigheter som Identum kräver för kundernas tredjepartssystem som Azure AD, Google Workspace och lokala Active Directory. Det betonas att åtkomsten är tillfällig, begränsad till projektperioden och följer principen om minsta möjliga privilegium. Dokumentet beskriver kraven för servicekonton, konsultåtkomst, serverkonfiguration och säkerhetsprotokoll, inklusive obligatorisk användning av MFA och inaktivering av konton efter projektet.