Okta와 임직원 보상 플랫폼을 안전하게 연동하려면 로그인 성공만 확인해서는 안 됩니다. 인증, 계정 생애주기, 그룹과 권한, 보상 잔액, 감사 증거를 서로 다른 통제로 설계해야 합니다. 통합 인증은 접속자의 신원을 증명하고 계정 프로비저닝은 계정이 존재해야 하는지를 다루지만, 무엇을 보고 보내고 승인하고 관리할 수 있는지는 보상 플랫폼이 승인된 정책에 따라 판단해야 합니다.
연결 설정보다 통제 경계를 먼저 정한다
Okta는 신원 제공자와 프로비저닝 클라이언트 역할을 할 수 있고, 보상 플랫폼은 서비스 제공자와 SCIM 서버 역할을 할 수 있습니다. 조달 문서에서는 이를 모두 ‘연동’이라 부르기 쉽지만, 네 가지 흐름은 서로 다른 문제를 해결합니다.
| 흐름 | 주요 역할 | 단독으로 결정하지 않을 사항 | 보관할 증거 |
| SAML 2.0 | 서명된 어설션을 이용한 브라우저 연합 로그인 | 수신자의 사용·승인·관리 권한 | 설정, 인증서, 어설션 시험, 로그인 기록 |
| OpenID Connect | 신원 토큰을 이용한 웹·모바일 인증 | 프로비저닝 상태나 보상 소유권 | 발급자, 클라이언트, 리디렉션 주소, 토큰 검증 |
| SCIM 2.0 | 사용자 생성·조회·수정·비활성화와 선택적 그룹 관리 | 기존 세션 철회나 잔액의 회계 처리 | 요청, 응답, 상관 식별자, 재시도, 대사 결과 |
| 보상 권한 부여 | 승인된 그룹·역할 정책을 플랫폼 권한으로 변환 | 신원 진위나 재직 상태 | 역할표, 승인 기록, 특권 작업 기록 |
올바른 SAML 어설션이나 OpenID Connect 토큰이 들어와도 그것만으로 관리자가 되어서는 안 됩니다. 애플리케이션은 인증된 주체를 테넌트 안의 불변 계정에 연결한 뒤 자체 권한 정책을 적용해야 합니다. 마찬가지로 active=true는 신원이 활성 상태라는 뜻일 뿐, 예산 책임자·승인자·발송자·관리자임을 증명하지 않습니다.
인증은 “누구인가”, 프로비저닝은 “계정이 있어야 하는가”, 권한 부여는 “무엇을 할 수 있는가”, 보상 원장은 “가치가 누구에게 속하는가”를 답합니다. 네 가지 답을 분리하고 감사할 수 있어야 합니다.
속성 매핑 전에 지속 가능한 식별자를 고른다
전자우편 주소는 편리하지만 주 키로는 불안정합니다. 이름과 도메인이 바뀌고, 계열사로 이동하거나 계약직에서 정규직으로 전환되며, 예전 별칭이 재사용되기도 합니다. 가능하면 인사 원천 시스템의 변경되지 않는 인력 식별자를 업무 키로 삼아 externalId 또는 통제된 기업 확장 속성으로 전달합니다. userName은 고유 로그인 또는 디렉터리 식별자로 다루되, 잔액이나 감사 이력의 유일한 소유 키로 사용하지 않습니다.
RFC 7643의 SCIM 핵심 스키마는 id를 서비스 제공자가 발급하는 안정 식별자로, externalId를 클라이언트가 상관관계를 위해 제공하는 식별자로 정의합니다. 따라서 다음 세 계층을 사용합니다.
- 보상 플랫폼이 내부
id를 발급하고 다시 배정하지 않습니다. - Okta가 권위 있는 인력 키를
externalId로 보냅니다. - 전자우편, 표시 이름, 부서는 변경 가능한 속성으로 유지하며 잔액과 이력의 주 키로 삼지 않습니다. 설정에 앞서 데이터 권위표를 작성합니다. 각 속성의 소유 시스템, 허용 방향, 빈값 처리, 변경 결과를 적습니다. 최소 프로필에는 대체로 인력 키, 로그인 식별자, 회사 전자우편, 표시 이름, 언어, 국가 또는 시장, 조직 단위, 생애주기 상태만 필요합니다. 생년월일, 집 주소, 보수, 개인 전화번호, 전체 인사 기록은 문서화된 용도와 개인정보 검토가 없다면 보내지 않습니다.
| 속성 | 권위 원천 | 방향 | 통제 주의점 |
| 인력 키 | 인사 시스템 | 인사에서 Okta를 거쳐 보상 플랫폼으로 | 불변이며 재사용하지 않음 |
| 회사 전자우편 | 인사 또는 디렉터리 | 하류로 | 변경 가능, 잔액 키로 쓰지 않음 |
| 언어와 국가 | 인사, 통제된 정정 허용 | 하류로 | 경험과 배송에 사용, 특권에는 미사용 |
| 보상 역할 | 승인된 접근 정책 | 그룹 또는 권한 매핑 | 직함 문구로 추론하지 않음 |
| 보상 잔액 | 보상 원장 | SCIM으로 기록하지 않음 | 독립된 업무 규칙으로 처리 |
장애가 나면 안전한 쪽으로 수렴하는 로그인을 만든다
SAML을 사용할 때는 운영 테넌트나 격리 환경마다 전용 애플리케이션 인스턴스를 둡니다. 설정된 인증서로 서명을 검증하고, 발급자·대상·어설션 수신 주소를 제한하며, 합리적인 시계 오차만 허용하고 재생된 어설션을 거부합니다. 플랫폼이 응답과 어설션 서명을 모두 지원하면 둘 다 검증합니다. NameID 형식을 문서화하고 프로비저닝과 같은 계정 해석 전략에 연결합니다. OpenID Connect에서는 발급자, 대상, 서명, 만료, nonce, 허용된 리디렉션 주소를 검증합니다. 공개 클라이언트에는 증명 키를 결합한 인증 코드 방식을 사용합니다. 올바른 토큰 의미를 명시적으로 구현하지 않았다면 접근 토큰을 신원 증명으로 사용하지 않습니다. 클라이언트 비밀은 비밀 관리 시스템에 저장하고, 평문 작업 요청서가 아니라 시험한 절차로 교체합니다. 어느 방식도 최초 로그인 때 특권 계정을 조용히 만들면 안 됩니다. 즉시 생성이 필요하면 테넌트 소속과 승인된 도메인 또는 클레임을 확인한 낮은 권한의 수신자 경험으로 제한합니다. 관리자 역할은 별도로 명시 배정하고 독립적으로 검토할 수 있어야 합니다. 출시 전에 다음을 시험합니다.
- 배정된 사용자가 올바른 테넌트와 역할에 도달합니다.
- 미배정 사용자를 거부하고 그림자 계정을 만들지 않습니다.
- 잘못된 발급자, 대상, 서명, 목적지, nonce, 만료 토큰을 거부합니다.
- 전자우편 주소가 바뀌어도 같은 불변 계정으로 연결됩니다.
- 비활성 사용자는 새 세션을 만들 수 없고 기존 세션도 문서화된 시간 안에 철회됩니다.
- 비상 계정은 분리·감시·기한 설정되며 일상 운영에 사용되지 않습니다.
SCIM을 대사 가능한 상태 기계로 구현한다
Okta의 SCIM 연동 안내에 따르면 Okta가 클라이언트로서 서비스 제공자의 종단점을 호출합니다. 서버는 계약에서 약속한 작업을 정확히 지원하고 표준에 맞는 상태 코드와 오류 본문을 반환해야 합니다. 그룹 관리가 실제 요구가 아니라면 사용자 생성·조회·수정·비활성화를 먼저 안정화합니다. 시험용 사용자 내용은 의도적으로 작게 유지할 수 있습니다.
{
"schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
"userName": "worker-00427",
"externalId": "hr-00427",
"active": true,
"name": {"givenName": "Asha", "familyName": "Patel"},
"emails": [{"value": "asha.patel@example.com", "type": "work", "primary": true}]
}
이 예시는 비밀이나 실제 임직원 정보를 포함하지 않습니다. 서버는 자체 안정 id와 자원 메타데이터를 돌려줍니다. 이후 기록에서는 문서화된 필터, 흔히 userName 또는 externalId로 기존 자원을 찾은 뒤 수정합니다. 중복 생성은 두 번째 계정을 만드는 대신 명확한 충돌 응답을 반환해야 합니다.
비활성화는 이력 삭제가 아니라 대체로 active를 false로 설정하는 일입니다. 표준 형태의 부분 수정 요청은 다음과 같습니다.
{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
"Operations": [{"op": "Replace", "path": "active", "value": false}]
}
같은 생성, 수정, 소속 변경, 비활성화가 반복되어도 같은 상태로 수렴하게 합니다. 테넌트, 작업, 자원 식별자, 결과, 상관 식별자, 지연 시간을 기록하되 bearer 토큰과 불필요한 개인정보는 제거합니다. 서버가 HTTP 429를 반환하면 합의한 재시도 계약과 유효한 정수 Retry-After를 따릅니다. 재시도가 소진되거나 순서가 뒤집힐 수 있으므로 정기 대사는 반드시 필요합니다.
조직도를 그대로 권한표로 바꾸지 않는다
그룹 푸시는 양쪽이 그룹의 의미에 합의했을 때만 유용합니다. 인사 부서는 애플리케이션 역할이 아닙니다. ‘영업’ 그룹을 무제한 보상 발송 권한으로 바꾸거나 관리 직함만으로 예산 승인을 허용하면 안 됩니다. 용도가 좁은 애플리케이션 전용 그룹을 만듭니다.
| Okta 그룹 | 플랫폼 역할 | 허용 작업 | 명시적 제외 |
| Rewards-Recipients | 수신자 | 개인 보상 조회와 수령 | 발송, 예산, 내보내기, 테넌트 설정 제외 |
| Rewards-Senders | 발송자 | 배정된 프로그램과 예산 안에서 선물 생성 | 역할 관리와 전체 내보내기 제외 |
| Rewards-Approvers | 승인자 | 정해진 한도 안에서 요청 승인 | 비밀 및 신원 설정 관리 제외 |
| Rewards-Auditors | 읽기 전용 감사자 | 승인된 감사·재무 보고서 조회 | 운영 변경 제외 |
| Rewards-Admins | 테넌트 관리자 | 범위가 제한된 설정과 배정 관리 | 보상 소유와 원장 수정 제외 |
한 사용자가 여러 그룹에 속할 때의 우선 규칙을 정합니다. 기본은 권한을 더하되 충돌이 있으면 명시적 거부나 격리 상태로 보냅니다. 대량 내보내기, 예산 변경, 신원 설정, 테넌트 소유권 같은 고위험 기능은 별도 승인과 추가 인증으로 보호합니다. 특권 그룹은 적어도 분기마다, 조직 변경이 구성원 범위를 넓힐 때마다 검토합니다. 보상 원장은 신원 프로비저닝에서 분리해야 합니다. 접근 중지가 이미 획득한 가치를 지우거나 상사에게 이전하거나 관리자가 사용할 수 있게 해서는 안 됩니다. 회사 지원 미사용 예산을 만료·환수·유지할지, 개인 보상을 퇴사 후에도 받을 수 있는지는 정책 책임자, 재무, 법무가 결정합니다. 플랫폼은 승인된 결정을 감사 가능한 거래로 실행해야 하며, SCIM의 부수 효과로 처리하면 안 됩니다.
퇴사, 휴직, 재입사를 서로 다른 사건으로 설계한다
퇴사는 ‘로그인 실패’만 확인하면 끝나지 않습니다. 실행 절차는 계정 상태, 기존 세션, 특권, 예약된 캠페인, 진행 중 승인, 애플리케이션 자격 정보, 데이터 보존, 보상 가치를 함께 다뤄야 합니다. 시간순으로 책임을 정합니다.
- 인사 원천이 안정 인력 키와 함께 발효 생애주기 사건을 게시합니다.
- Okta가 정책에 따라 신원을 정지 또는 비활성화하고 하류 변경을 보냅니다.
- 보상 플랫폼이 새 세션과 특권 작업을 차단하고, 기존 세션을 철회하거나 단축하며, 계정을 비활성화합니다.
- 진행 중 승인을 취소하거나 다시 배정하고 프로그램 관리 권한을 제거합니다.
- 별도 업무 규칙으로 미사용 예산과 개인 잔액을 처리하되 원장은 보존합니다.
- 감시가 모든 시스템의 수렴을 확인하고, 목표 시간을 넘긴 활성 상태가 있으면 사고 기록을 엽니다. 휴직은 일시 정지, 퇴사는 접근 제거와 보존, 재입사는 현재 역할 재계산이 필요합니다. 안정 인력 식별자가 동일인임을 증명할 때만 원래 계정을 다시 활성화합니다. 인사 시스템이 새 식별자를 발급했다면 이름이나 전자우편 일치만으로 자동 병합하지 말고 승인된 연결 판단을 거칩니다.
흔한 예외는 어떻게 처리해야 하는가?
중복 사용자: 새 배정을 격리하고 불변 식별자를 비교합니다. 양쪽 감사 흔적을 보존하는 승인 절차를 통해서만 병합합니다.
오래된 그룹 소속: 파생 역할을 제거하고 전후 상태를 기록하며 영향을 받은 그룹의 모든 사용자를 다시 대사합니다.
재입사: 신원 연속성이 증명될 때만 원래 계정을 활성화하고, 옛 특권을 복원하지 말고 현재 정책으로 역할을 다시 계산합니다.
SCIM 장애: 안전하지 않은 권한 확대를 거부하고 반복 실행 가능한 작업을 대기열에 넣고 운영자에게 알리며 복구 뒤 대사합니다. 로그인 성공이 오래된 프로비저닝 상태를 우회하게 하지 않습니다.
퇴사자 비활성화 실패: 플랫폼 비상 통제로 접근을 철회하고 증거를 보존하며 연결 오류를 고친 뒤 생애주기 사건을 다시 실행합니다.
녹색 연결 표시보다 시험 증거가 중요하다
운영 준비 검토는 정상 경로와 실패 억제를 모두 증명해야 합니다. 합성 사용자만 있는 비운영 테넌트에서 생성, 연결, 수정, 그룹 추가·제거, 비활성화, 재활성화, 이름 변경, 중복, 속도 제한, 시간 초과, 잘못된 토큰, 순서 역전을 시험합니다. 요청과 응답의 필요한 메타데이터는 보관하되 비밀은 남기지 않습니다. 보안과 운영이 행동으로 옮길 수 있는 지표를 측정합니다.
- 프로비저닝 수렴 시간의 중앙값과 높은 백분위 값.
- 인사 퇴사 사건에서 플랫폼 접근 차단까지 걸린 시간.
- 중복 계정 비율과 해결되지 않은 신원 예외.
- 종단점, 상태 코드, 테넌트별 실패 작업.
- 특권 그룹 인원과 승인 시간 밖 변경.
- Okta 배정과 플랫폼 상태 사이의 대사 차이.
- 유효한 상관 식별자와 감사 증거가 있는 사건 비율. 기록은 누가 변경을 시작했고, 어떤 권위 사건이 원인이었고, 연결 장치가 무엇을 보냈고, 플랫폼이 권한을 어떻게 평가했고, 어떤 상태가 바뀌었고, 복구가 끝났는지 답해야 합니다. 문서화된 기간 동안 보관하고 접근을 제한하며 감사 전에 실제 내보내기를 시험합니다. 요약 화면만 있고 원시 상관 증거로 돌아갈 수 없다면 충분하지 않습니다. 가용성뿐 아니라 업무 안전을 포함한 목표를 정합니다. 예를 들어 “일반 프로비저닝 수정의 99%가 15분 안에 수렴하고, 긴급 퇴사는 5분 안에 새 접근을 차단하며, 초과 시 신원 운영 책임자에게 알리고 추적 가능한 사고를 연다”라고 정할 수 있습니다. 다만 실제 구조와 인력이 지킬 수 있는 값이어야 합니다.
단계적으로 출시하고 조달에 쓸 수 있는 인수 기록을 남긴다
연동 관리자, 소규모 부서 간 시험, 한 사업부, 전체 인원 순으로 넓힙니다. 시험 기간에는 일반 사용자의 수동 계정 생성을 꺼 두어 예정된 통제 경로 자체를 검증합니다. 각 관찰 기간에는 매핑을 고정하고, 이후 한 번에 변수 하나만 바꿉니다. 프로그램 전체 거버넌스에는 직원 인정 플랫폼 구축 가이드를, 주변 시스템 경계에는 기업 선물 연동 아키텍처를 함께 활용할 수 있습니다. 인수 기록에는 구조도, 데이터 흐름 목록, 속성표, 프로토콜 설정, 인증서와 키 교체 계획, 그룹·역할표, 퇴사 의사결정 절차, 시험 사례, 결과, 미해결 위험, 책임자, 승인 날짜가 포함되어야 합니다. 조달팀은 테넌트 격리, 감사 내보내기, 사고 대응, 보존과 삭제, 하위 처리자, 지역별 데이터 처리, 관리자 복구 방식도 물어야 합니다. 출시 전 최종 확인 사항입니다.
- 안정 식별자가 전자우편, 이름, 조직 변경 뒤에도 같은 사람을 연결합니다.
- 로그인과 프로비저닝이 각각 안전한 방식으로 실패합니다.
- 어떤 SCIM 속성도 보상 잔액을 쓰거나 스스로 특권을 배정할 수 없습니다.
- 그룹 제거가 그룹 추가와 같은 신뢰도로 접근을 줄입니다.
- 퇴사, 휴직, 재입사를 각각 시험했습니다.
- 토큰, 인증서, 클라이언트 비밀에 책임자와 교체 증거가 있습니다.
- 대사가 한쪽에만 활성화된 사용자를 찾아냅니다.
- 감사 내보내기가 인사 사건, Okta 작업, 플랫폼 판단, 복구를 연결합니다. 올바른 결과는 “Okta 연결됨”이라는 표시가 아닙니다. 변경, 장애, 조사 상황에서도 이해할 수 있는 생애주기입니다. 신원 증명, 계정 상태, 애플리케이션 권한, 보상 회계를 나누고 안정 식별자와 시험 가능한 증거로 수렴시켜야 합니다. 선택한 보상 플랫폼이 필요한 신원 통제를 지원한다면 Giftpack은 통제된 임직원 선물과 이행을 위한 실행 계층으로 사용할 수 있습니다. 신원, 보안, 인사, 법무, 재무 부서는 접근 정책, 고용 판단, 데이터 사용, 잔액 처리의 책임을 계속 지며, Giftpack은 승인된 결정을 구현합니다. 이러한 전문 판단을 대신하지 않습니다.