엔터프라이즈 AI 접근 통제는 어떻게 작동해야 할까?

엔터프라이즈 AI 개발 워크스페이스에서는 생성된 모든 변경을 특정 환경에서 정해진 역할을 통해 사람의 신원으로 수행한 작업으로 다뤄야 합니다. 플랫폼이 소스를 읽고, 외부 서비스를 호출하고, 인프라를 만들고, 앱을 배포하고, 스냅샷을 복원하거나 코드를 내보낼 수 있다면 그 접근 모델은 영리한 편집기가 아니라 프로덕션 시스템을 통제합니다.

조달 과정에서 가장 흔한 실수는 기능 목록에 SAML, SCIM, RBAC가 있는지만 확인하는 일입니다. 제공 여부만으로는 실제 강제를 알 수 없습니다. 공급업체는 SAML 어설션을 받으면서 비밀번호 로그인을 열어 둘 수 있고, SCIM 정지를 처리하면서 활성 세션을 유지할 수 있으며, RBAC를 내세우면서 모든 빌더에게 배포 권한을 줄 수 있습니다. 구매자는 ID 공급자에서 최종 결과까지 이어지는 경로를 시험해야 합니다.

인증, 수명 주기 관리, 권한 부여, 승인, 자격 증명 처리, 환경 격리, 감사 증거는 각각 다른 문제를 해결합니다. 이를 막연히 보안이라는 제목 아래 묶으면 통제 수단 사이의 빈틈이 가려집니다. 그 틈에서 퇴직자가 세션을 유지하고, 개발 에이전트가 프로덕션 자격 증명에 접근하며, 승인된 변경이 릴리스 전에 바뀝니다.

SAML은 우회 로그인 경로를 없애야 합니다

SAML SSO는 워크스페이스에 들어오는 일반적이고 강제 가능한 경로가 엔터프라이즈 ID 공급자가 되게 해야 합니다. 공급업체 비밀번호 양식 옆의 선택 버튼이어서는 안 됩니다. 회사 도메인을 등록하면 해당 도메인에서 관리되지 않는 신원을 만드는 자체 가입, 비밀번호 복구, 초대를 막아야 합니다.

OASIS SAML 2.0 사양은 인증과 속성에 관한 어설션을 정의합니다. 누군가 퇴사했을 때 공급업체 계정을 비활성화하지 않으며, 인증된 엔지니어가 프로덕션에 배포해도 되는지도 결정하지 않습니다. 조달 설문지는 SAML을 중앙 접근 통제의 증거로 취급하는 경우가 많지만, SAML이 입증하는 것은 인증의 일부뿐이므로 이 경계가 중요합니다.

제대로 된 구현은 어설션 서명, 발급자, 대상, 수신자, 시간 조건, 요청 상관관계를 검증합니다. 장애 없이 인증서를 교체할 수 있어야 하며, 변경되지 않는 식별자로 사용자를 매핑해야 합니다. 이메일은 주소가 바뀌거나 재사용될 수 있고 서식만 다른 경우도 있어서 주 식별자로 적합하지 않습니다. 어떤 SAML 속성이 영속적인 계정 신원이 되는지, 그 속성이 바뀌면 어떻게 되는지 물어보세요.

관리자는 세션 기간, 비활성 제한, 민감한 작업을 위한 재인증을 설정할 수 있어야 합니다. 정책이 다중 인증에 의존한다면 워크스페이스는 ID 공급자의 인증 컨텍스트를 존중해야 합니다. ID 공급자가 발급한 어떤 어설션이든 받으면서 SAML이 자동으로 강력한 인증을 제공한다고 주장해서는 안 됩니다.

로컬 비상 접근은 매우 좁은 예외로 두어야 합니다. ID 공급자 장애가 모든 관리자를 잠그지 않도록 일반 SSO 경로 밖에 하나 이상의 비상 계정을 두세요. 강력한 인증, 분리된 보관 책임, 즉시 알림, 문서화된 테스트 일정을 적용해야 합니다. 일반 관리자가 편의상 이 계정을 사용해서는 안 됩니다.

로그인 버튼만 보지 말고 우회 경로를 테스트하세요. 오래된 초대를 열고, 비밀번호 재설정을 요청하고, 사용자의 이메일을 바꾸고, 허용된 ID 공급자 그룹에서 사용자를 제거하고, 잘못된 테넌트에 ID 공급자 시작 로그인을 시도하세요. 워크스페이스가 게스트 도메인, 인수한 회사 도메인, 여러 ID 공급자를 어떻게 처리하는지 확인합니다. 공급업체가 손을 흔들 듯 अस्पष्ट하게 설명하지 않고 계정 연결을 설명하지 못한다면 중복 신원이 생길 것으로 보아야 합니다.

세션 종료는 별도의 승인 기준이 필요합니다. ID 공급자에서 사용자를 비활성화하면 다음 로그인을 막을 수는 있지만, 기존 브라우저 세션, 명령줄 토큰, 에이전트 작업은 몇 시간 더 계속될 수 있습니다. 관리자가 한 신원의 모든 세션을 해지할 수 있는지, SCIM 정지가 그 작업을 자동으로 실행하는지 확인하세요.

SCIM은 사람의 기억에 의존하지 않고 계정을 닫아야 합니다

ID 소스가 사용자를 정지할 때 SCIM은 대화형 세션, API 자격 증명, 대기 중인 작업, 에이전트 실행 전반에서 실질적인 접근을 신속하게 제거해야 합니다. 계정 필드를 비활성으로 설정하는 것만으로는 퇴사 처리가 끝나지 않습니다.

RFC 7643은 핵심 User 및 Group 리소스 스키마를 정의하고, RFC 7644는 이러한 리소스를 생성, 조회, 수정, 삭제하기 위한 프로토콜 작업을 정의합니다. 표준은 공급업체에 공통 교환 방식을 제공하지만, 비활성화의 모든 로컬 결과를 정하지는 않습니다. 구매자는 변경을 받은 뒤 워크스페이스가 실제로 무엇을 하는지 물어야 합니다.

프로비저닝은 첫 로그인 전에 올바른 조직과 기본 그룹 멤버십으로 계정을 만들어야 합니다. 그룹 업데이트는 워크스페이스 역할을 예측 가능하게 추가하고 제거해야 합니다. 정지는 새 세션을 거부하고, 기존 세션과 개인 토큰을 해지하며, 예약된 작업을 중단하거나 재배정하고, 정지된 신원으로 대기 중인 승인을 실행하지 못하게 해야 합니다. 삭제는 감사 귀속을 지우지 않으면서 고객의 보존 정책을 따라야 합니다.

흔한 실패 사례는 릴리스 그룹에 속한 계약직에서 시작합니다. ID 공급자가 계약직을 그룹에서 제거하고 SCIM 패치를 보냅니다. 워크스페이스는 화면에 보이는 역할을 업데이트하지만, 이전 브라우저 세션에는 여전히 릴리스 권한이 남아 있습니다. 제거 전에 계약직이 대기시킨 배포도 나중에 서비스 자격 증명으로 실행됩니다. 모든 화면은 올바르게 보이지만 실질적인 접근은 두 곳에서 살아 있습니다.

이 실패는 디렉터리 상태와 실행 중 권한의 차이를 드러냅니다. SCIM은 디렉터리 상태를 업데이트합니다. 워크스페이스는 이 변경을 세션, 토큰, 작업, 승인 할당, 캐시된 권한 결정으로 전파해야 합니다. 조달에서는 예상 해지 시간을 정하고 측정해야 하며, 즉시나 자동 같은 말만 받아들여서는 안 됩니다.

그룹 조정도 테스트가 필요합니다. 사용자를 한 그룹에서는 제거하되 다른 그룹에는 남겨 두고, 정지했다가 재활성화하고, 그룹 이름을 바꾸고, 프로덕션 접근을 부여하는 그룹을 삭제하세요. 재활성화해도 사용자가 더는 속하지 않은 그룹에서 온 권한이 복구되어서는 안 됩니다. 수동 역할 부여는 그룹 정리 후에도 남을 수 있으므로 따로 보이게 해야 합니다.

SCIM 커넥터 자체도 점검하세요. 베어러 토큰에는 프로비저닝 권한만 있어야 하고, 교체를 지원하며, 설정과 사용에 대한 감사 이벤트를 남겨야 합니다. 서비스 공급자는 유용한 오류 응답을 제공하고 안전한 재시도를 견뎌야 합니다. 그룹 변경을 조용히 버리는 커넥터는 ID 팀을 무급 모니터링 소프트웨어로 만듭니다.

RBAC는 작업을 리소스에 연결해야 합니다

RBAC는 어떤 신원이 어떤 리소스에서 어떤 작업을 어느 환경에서 수행할 수 있는지 표현해야 합니다. 넓은 범위의 뷰어, 멤버, 관리자 라벨만으로는 소프트웨어를 만들고 릴리스하는 워크스페이스를 안전하게 관리할 수 없습니다.

직책이 아니라 작업에서 시작하세요. 권한 카탈로그는 프로젝트 보기, 지침 편집, 에이전트 실행, 생성된 소스 읽기, 소스 내보내기, 스냅샷 관리, 버전 복원, 도메인 설정, 배포 생성, 아티팩트 승격, 시크릿 메타데이터 읽기, 자격 증명 변경, 감사 기록 읽기, 조직 정책 변경을 구분해야 합니다. 정확한 명사는 플랫폼마다 다르지만, 그 구분이 사라져서는 안 됩니다.

실행 가능한 시작 매트릭스는 다음과 같습니다.

이 표를 그대로 복사하지 마세요. 명시적인 결정을 내려야 하는 조합을 찾는 데 활용하세요. 일부 조직은 승인자와 운영자를 겸임하게 하고, 규제 대상 팀은 분리합니다. 위험한 기본값은 변경 생성, 승인, 자격 증명 추가, 배포, 증거 삭제를 모두 할 수 있는 일반 관리자입니다.

역할에는 범위가 필요합니다. 엔지니어는 한 워크스페이스에서는 빌드하고 다른 곳에서는 검토하며 세 번째에는 접근하지 못할 수 있습니다. 개발 접근이 가능하다고 해서 프로덕션 권한이 자동으로 생겨서는 안 됩니다. 권한 엔진은 문서화된 상속 규칙과 함께 조직, 워크스페이스, 프로젝트, 환경, 리소스 범위를 지원해야 합니다. 구매자는 상위 범위의 허용이 하위 범위의 거부를 덮는지, 그 반대인지 알아야 합니다.

맞춤 역할은 공급업체가 안정적인 권한을 공개하고 실효 접근 권한을 보고할 때만 유용합니다. 간단한 조사 질문에 답하는 보기 또는 내보내기를 요청하세요. 이 신원이 왜 이 작업을 할 수 있는가? 답변에는 직접 할당, 그룹에서 파생된 역할, 상속된 권한, 임시 권한, 정책 조건이 나타나야 합니다. 이런 설명이 없으면 첫 조직 개편 뒤 맞춤 역할을 검토하기가 어려워집니다.

사람 역할과 워크로드 신원도 별도로 다뤄야 합니다. 배포 에이전트는 생성자의 전체 대화형 역할을 빌려서는 안 되며, 서비스 신원은 사용자 인터페이스에 로그인해서는 안 됩니다. 각 워크로드에 이름 있는 소유자, 용도, 환경, 권한 집합, 만료일 또는 검토일, 해지 경로를 부여하세요.

환경에는 실제 보안 경계가 필요합니다

개발, 테스트, 프로덕션은 강제된 권한, 자격 증명, 런타임 리소스, 데이터 정책, 릴리스 경로로 구분되어야 합니다. 환경 선택기나 색깔 라벨만으로는 격리가 생기지 않습니다.

첫 번째 경계는 권한 부여입니다. 개발 리소스를 변경할 수 있는 빌더가 같은 상속 프로젝트 역할을 통해 프로덕션에 접근해서는 안 됩니다. 두 번째는 자격 증명입니다. 개발 에이전트에는 개발 데이터베이스와 클라우드 권한을 주고, 모든 환경에 도달할 수 있는 조직 자격 증명은 절대 주지 마세요. 세 번째는 데이터입니다. 별도 절차가 그 사용을 승인하고 보호하지 않는 한 미리보기와 테스트에서 프로덕션 기록을 복사해서는 안 됩니다.

생성된 앱이 외부 호출을 하거나 인프라를 만들 수 있다면 런타임 분리가 중요합니다. 환경마다 실행 신원, 네트워크 규칙, 저장 위치, 배포 대상이 다른지 물어보세요. 하나의 공유 워커가 여러 환경을 처리한다면 플랫폼이 한 작업이 다른 작업의 자료를 읽지 못하게 하는 방법을 확인하세요. 논리적 분리라는 주장은 아키텍처 슬라이드가 아니라 통제 시연이 필요합니다.

승격은 더 넓은 프로덕션 권한 아래에서 변경 가능한 소스를 다시 빌드하는 대신, 검토된 아티팩트를 옮겨야 합니다. 소스 리비전, 생성 파일, 종속성 잠금 상태, 테스트 결과, 정책 버전, 아티팩트 다이제스트를 기록하세요. 프로덕션이 최신 프로젝트 상태에서 다시 빌드되면 승인 후에 생긴 변경이 검토 없이 릴리스에 들어갈 수 있습니다.

스냅샷과 롤백에도 같은 경계가 필요합니다. 이전 앱 버전을 복원하면 취약한 코드, 오래된 설정, 더는 데이터베이스와 맞지 않는 스키마 기대값도 함께 복원될 수 있습니다. 프로덕션 롤백은 권한 부여, 증거, 감사 추적이 필요한 프로덕션 작업으로 다루세요. 롤백이라는 안심되는 단어가 릴리스 정책을 우회하게 두지 마세요.

데이터 레지던시와 환경 분리는 관련은 있지만 다릅니다. 선택한 국가에서 워크로드를 실행하면 저장 또는 전송 요구사항을 충족할 수 있지만, 개발과 프로덕션이 별도의 신원이나 데이터를 쓴다는 증거는 아닙니다. 조달팀은 하나의 위치 주장이 두 질문에 답하게 하지 말고 두 요구사항을 모두 문서화해야 합니다.

공급업체가 한 조직 안에서 이 경계를 강제할 수 없다면 별도 테넌트가 필요할 수 있습니다. 관리 부담이 늘고 승격이 복잡해질 수 있지만, 프로젝트 라벨이 프로덕션 권한을 담고 있다고 가장하는 것보다 안전합니다.

승인 게이트는 중요한 경계에 있어야 합니다

승인 게이트는 실질적인 결과를 만드는 작업을 보호해야 하며, 각 승인은 변경되지 않는 하나의 제안에 연결되어야 합니다. 모든 에이전트 메시지에 승인을 요구하면 피로가 쌓이고, 모호한 대화를 승인하면 검토자에게 정보가 너무 적습니다.

좋은 후보는 프로덕션 배포, 자격 증명 추가 또는 범위 확대, 네트워크 노출 변경, 공개 도메인 설정, 민감한 소스나 데이터 내보내기, 프로덕션 스냅샷 복원, 권한 정책 변경, 감사 내보내기 비활성화입니다. 개발 편집은 보호된 데이터나 외부 시스템을 건드리지 않는 한 같은 게이트가 보통 필요하지 않습니다.

검토자는 요청 작업, 대상 환경, 소스와 아티팩트 다이제스트, 파일 또는 인프라 diff, 테스트, 정책 결과, 요청한 자격 증명 범위, 요청자 신원, 에이전트 신원, 만료 시간을 담은 구체적인 패킷이 필요합니다. 인터페이스는 검토자가 승인하면 무엇이 일어나는지 밝혀야 합니다. 작업 경계 없이 허용이라고 쓰인 버튼은 승인 통제가 아닙니다.

정책 자체는 구매자가 점검하고 테스트할 수 있는 형태로 표현할 수 있습니다.

policy_version: 18
rules:
  - action: deploy
    environment: production
    require:
      approvals: 1
      approver_role: release_approver
      requester_cannot_approve: true
      artifact_digest_must_match: true
      expires_minutes: 30
  - action: credential_scope_change
    require:
      approvals: 1
      approver_role: credential_custodian
      scope_diff_required: true

이 조각은 두 가지 흔한 실패를 막습니다. 요청자는 자신의 프로덕션 배포를 승인할 수 없고, 다이제스트가 더는 일치하지 않으므로 아티팩트 변경은 승인을 무효로 만듭니다. 짧은 만료 시간은 주변 운영 상황이 달라진 뒤 오래된 결정을 실행하는 일도 막습니다.

승인 상태는 채팅 스레드나 사용자 세션이 아니라 작업과 함께 움직여야 합니다. 소스를 편집하거나, 대상을 바꾸거나, 권한을 확대하거나, 자격 증명을 교체하거나, 생성을 다시 실행해 승인된 제안이 바뀌면 새 결정이 필요합니다. 실패한 배포 재시도는 아티팩트와 작업이 동일하고 정책이 명시적으로 허용할 때만 기존 승인을 재사용할 수 있습니다.

대기 중인 작업과 자동 작업에도 같은 강제가 필요합니다. 에이전트가 승인된 시간대에 프로덕션 변경을 예약한 뒤 그 시간이 끝난 후 다른 버전을 실행해서는 안 됩니다. 실행 서비스는 실행 시점에 권한, 승인 유효성, 아티팩트 신원, 자격 증명 범위를 다시 확인해야 합니다.

계획 모드는 검토자가 의도한 작업을 이해하도록 도울 수 있지만, 계획은 권한 경계가 아닙니다. 플랫폼은 정확한 계획을 생성한 뒤 도구 호출이 바뀌거나, 통합 서비스가 예상 밖 데이터를 반환하거나, 모델이 접근 방식을 수정했기 때문에 추가 작업을 할 수 있습니다. 효과를 일으키는 작업에서 승인을 강제하세요.

실제 사고에 대비한 비상 경로는 있어야 합니다. 사유, 제한된 기간, 제한된 작업 집합, 즉시 알림, 사용 후 검토를 요구하세요. 비상 재정의가 조용히 영구 관리자 접근을 부여한다면 예외가 통제를 대체한 것입니다.

자격 증명은 사람들이 잊기 전에 만료되어야 합니다

대상 시스템이 지원한다면 워크스페이스는 좁은 환경 및 작업 범위를 가진 임시 워크로드 자격 증명을 사용해야 합니다. 채팅, 프로젝트 설정, 빌드 변수에 넣은 영구 조직 토큰은 대부분의 작업에 필요한 것보다 훨씬 큰 권한을 에이전트에 줍니다.

세 가지 개념을 구분하세요. 사람 세션은 누가 워크스페이스를 쓰는지 증명합니다. 워크로드 신원은 에이전트, 빌드 또는 배포 프로세스를 식별합니다. 시크릿 자료는 그 워크로드가 외부 시스템에 접근하도록 허용합니다. 세 가지 모두에 사람의 광범위한 토큰을 재사용하면 귀속이 무너지고 해지가 혼란스러워집니다.

검증된 워크로드 신원을 임시 토큰으로 교환하는 연합 인증이나 자격 증명 브로커를 선호하세요. 브로커는 대상, 역할, 환경, 기간을 제한할 수 있습니다. 에이전트 프로세스는 승인된 도구를 호출할 때만 토큰을 받아야 하며, 모델이 컨텍스트에서 시크릿 값을 보거나 재생산해서는 안 됩니다.

시크릿 저장만으로는 범위 문제가 해결되지 않습니다. 완벽하게 암호화된 클라우드 자격 증명도 모든 계정에서 삭제를 허용할 수 있습니다. 볼트만 보지 말고 대상 권한을 검토하세요. 각 자격 증명에는 소유자, 용도, 허용 환경, 승인된 워크로드, 생성 출처, 교체 방법, 마지막 사용 기록이 있어야 합니다.

프롬프트, 채팅 기록, 생성된 소스, 로그, 스냅샷, 지원 번들, 내보내기는 모두 유출 경로가 될 수 있습니다. 플랫폼은 저장 전에 감지된 시크릿을 마스킹해야 하지만 형식이 다양하고 인코딩된 값은 빠져나가므로 감지는 보조 통제일 뿐입니다. 더 강한 설계는 시크릿 자료를 모델 입력이나 일반 출력 채널에 절대 넣지 않습니다.

소스 내보내기에는 의도적인 규칙이 필요합니다. 내보내기 패키지는 시크릿 값을 빼고 해결되지 않은 시크릿 참조를 식별하여 받는 팀이 무엇을 설정해야 하는지 알게 해야 합니다. 작동하는 환경 파일을 포함하는 내보내기는 이식성을 자격 증명 배포로 바꿉니다.

실제 권한이 없는 카나리아 자격 증명으로 격리를 테스트하세요. 알아볼 수 있는 값을 지원되는 각 입력 경로에 넣고, 에이전트를 실행하고, 스냅샷을 만들고, 로그를 살피고, 프로젝트를 내보내세요. 그런 다음 생성된 모든 아티팩트와 감사 스트림을 검색합니다. 이 테스트는 공급업체의 시크릿 경계가 직접 시크릿 입력뿐 아니라 일반 제품 기능을 견디는지 보여 줍니다.

교체와 해지는 워크스페이스 전체를 다시 빌드하지 않고 작동해야 합니다. 대상이 임시 자격 증명을 발급하지 못할 때 시스템이 어떻게 하는지, 저장된 시크릿을 어떻게 교체하는지, 작업이 실행 시점에 현재 버전을 가져오는지 물어보세요. 어제의 자격 증명을 잡아 둔 작업은 자격 증명 레코드가 업데이트된 것처럼 보여도 계속될 수 있습니다.

외부 연동에는 별도의 동의 모델이 필요합니다. 소스 저장소, 데이터베이스, 티켓 시스템, 클라우드 계정을 추가할 때 요청 범위를 보여 주고 연결을 워크스페이스와 환경에 묶어야 합니다. 한 프로젝트의 에이전트 실수가 모든 저장소나 계정을 노출해서는 안 되므로 조직 전체 연결은 예외적이어야 합니다.

내보낸 감사 로그는 의도와 결과를 재구성해야 합니다

감사 로그는 조사자가 공급업체 사용자 인터페이스에 의존하지 않고 사람의 요청을 권한 부여, 에이전트 실행, 자격 증명 사용, 결과 변경에 연결하게 해야 합니다. 내보내기 가능하다는 말은 관리자만 할 수 있는 수동 다운로드가 아니라 고객이 통제하는 저장소나 모니터링으로 이어지는 문서화된 연속 경로를 뜻합니다.

NIST SP 800-53은 AU-12의 감사 이벤트 생성과 AU-9의 감사 정보 보호를 구분합니다. 여기서도 이 구분은 유용합니다. 워크스페이스 관리자가 유일한 사본을 바꾸거나 지울 수 있다면 배포를 기록하는 것만으로는 부족합니다. 쓰기 접근을 제한하고 고객이 보존 기간을 통제하는 워크스페이스 밖으로 이벤트를 보내세요.

모든 이벤트에는 안정적인 식별자, 타임스탬프, 테넌트, 사람 행위자, 워크로드 또는 에이전트 신원, 작업, 대상 리소스, 환경, 권한 결정, 역할 또는 정책 근거, 승인 참조, 자격 증명 참조, 결과, 상관관계 식별자가 필요합니다. 변경 이벤트에는 diff, 안전한 변경 전후 값, 또는 이벤트를 저장된 아티팩트에 묶는 해시가 포함되어야 합니다.

배포 이벤트의 출력 형태는 다음과 같을 수 있습니다.

{
  "event_id": "evt_01J...",
  "occurred_at": "2026-07-27T14:03:22Z",
  "actor": {"type": "user", "id": "usr_1842"},
  "workload": {"type": "release_agent", "id": "agt_77"},
  "action": "deployment.create",
  "target": {"environment": "production", "application": "app_91"},
  "authorization": {
    "decision": "allow",
    "policy_version": 18,
    "approval_id": "apr_552"
  },
  "artifact_digest": "sha256:8b1c...",
  "credential_ref": "cred_cloud_prod_4",
  "request_id": "req_9031",
  "result": "success"
}

이 이벤트는 시크릿 값이 아니라 참조만 노출합니다. 사람과 실행 워크로드를 모두 명시하므로 에이전트가 배포했다는 식의 쓸모없는 기록을 막습니다. 요청 식별자는 관련 모델 실행, 도구 호출, 정책 결정, 대상 시스템 응답을 연결해야 합니다.

감사와 관측 가능성은 다릅니다. 운영 추적은 엔지니어가 지연, 모델 호출, 실패를 디버깅하도록 돕습니다. 감사 기록은 누가 어떤 작업을 할 권한을 받았고 무엇이 바뀌었는지 입증합니다. 공급업체는 풍부한 추적을 제공하면서 역할 변경, 시크릿 관리, 지원 접근, 내보내기 작업, 거부된 권한 시도를 빼기도 합니다.

프롬프트 내용은 절제가 필요합니다. 전체 프롬프트에는 소스 코드, 개인정보, 시크릿이 있을 수 있으므로 보안 로그에 모든 대화를 보관하면 또 다른 민감한 저장소가 생길 수 있습니다. 안정적인 해시, 마스킹된 요약, 별도 통제를 받는 콘텐츠 참조, 생성된 구체적 작업을 기록하세요. 고객에게 보존과 마스킹 통제권을 주되, 행동한 모델이 어떤 보안 이벤트를 없앨지 결정하게 해서는 안 됩니다.

순서, 시계 일관성, 전달 지연, 재시도, 중복 처리, 스키마 변경, 장애 시 동작을 테스트하세요. 내보내기는 버전 관리를 문서화하고 복구를 위한 커서나 이벤트 식별자를 제공해야 합니다. 고객 수신기가 사용할 수 없으면 공급업체는 공개한 한도에 따라 이벤트를 버퍼링하고 전달이 따라잡지 못할 때 알림을 보내야 합니다.

지원 접근도 같은 스트림에 들어가야 합니다. 공급업체 직원이 테넌트에 접근한 때, 이를 허용한 권한, 본 내용이나 변경한 내용, 접근 종료 시점을 기록하세요. 고객이 내보낼 수 없는 공급업체 내부 로그는 엔터프라이즈 조사를 뒷받침하지 못합니다.

조달 테스트는 통제 플레인을 공격해야 합니다

조달에서는 격리된 평가 테넌트에서 실시간 테스트를 요구하고, 관찰된 강제를 승인 증거로 다뤄야 합니다. 프레젠테이션은 아키텍처를 설명할 수 있지만, 정지된 사용자가 캐시된 배포 토큰을 잃는다는 사실까지 증명하지는 못합니다.

ID 공급자, SCIM 클라이언트, 여러 테스트 신원, 두 환경, 무해한 외부 자격 증명, 감사 수신기를 준비하세요. 세션 전에 예상 결과를 공급업체에 알려 주면 발표자의 즉흥 대응이 아니라 제품을 측정할 수 있습니다.

1. 로컬 비밀번호, 초대, 비밀번호 복구, 중복 이메일, 잘못된 ID 공급자, 정지 후 오래된 세션까지 모든 신원 우회 경로를 시도합니다.
2. 브라우저 세션, 개인 토큰, 대기 중 승인, 예약 작업, 에이전트 실행이 활성 상태인 동안 그룹 멤버십을 바꾸고 높은 권한 사용자를 정지합니다.
3. 상속 역할, 맞춤 역할, 서비스 신원, 소스 내보내기, 스냅샷 복원, 개발에서 프로덕션으로의 이동을 통해 권한 상승을 시도합니다.
4. 하나의 아티팩트를 승인하고 소스나 대상을 변경한 뒤, 오래된 승인과 더 넓은 자격 증명으로 배포를 시도합니다.
5. 모든 이벤트를 내보낸 후 거부된 시도와 공급업체 지원 접근을 포함해 누가 변경을 요청, 승인, 실행, 수신했는지 재구성합니다.

모든 결과에 대한 원시 증거를 기록하세요. 민감한 값을 뺀 SAML 응답 세부 정보, SCIM 요청 및 응답, 실효 권한 내보내기, 승인 식별자, 아티팩트 다이제스트, 자격 증명 메타데이터, 감사 이벤트, 타임스탬프가 여기에 포함됩니다. 스크린샷은 결과 설명에는 도움이 되지만, 공급업체가 통제를 바꾼 뒤 비교하기에는 기계가 읽을 수 있는 출력이 더 낫습니다.

결과 상태는 통과, 실패, 부분 충족, 약속됨의 네 가지를 쓰세요. 부분 충족은 일부 접근 경로, 리소스, 요금제에서만 통제가 작동한다는 뜻입니다. 약속됨은 공급업체가 미래 동작을 설명했다는 뜻입니다. 계정 팀이 로드맵 날짜를 준다고 해서 둘 중 어느 것도 통과로 바꾸지 마세요.

설정을 바꾼 뒤 실패한 테스트를 다시 하도록 공급업체에 요청하세요. 이로써 제품 통제가 없는 경우와 기본 설정이 좋지 않은 경우를 구분하고, 관리자가 설정을 찾을 수 있는지도 알 수 있습니다. 문서화되지 않은 지원 작업 뒤에 숨은 보안 기능은 실제 출시 때 다시 실패합니다.

요금제와 가격 경계도 함께 테스트하세요. SSO는 한 요금제에 있고 SCIM은 다른 요금제에 있으며, 감사 내보내기는 별도의 보존 또는 전달 한도가 있을 수 있습니다. 조달에는 개별적으로 제공되는 기능의 모음이 아니라 정책에 필요한 조합이 필요합니다. 각 승인 기준 옆에 요금제 자격과 사용량 한도를 적으세요.

관리 복구도 점검하세요. 마지막 조직 관리자를 제거하고, SAML 설정을 망가뜨리고, SCIM 토큰을 잘못 교체하고, 감사 수신기를 중단하세요. 워크스페이스는 보이지 않는 공급업체 우회 경로를 만들지 않으면서 통제된 복구를 제공해야 합니다. 복구 작업은 시스템에서 가장 강력한 감사 증거를 남겨야 합니다.

Koder.ai를 평가할 때는 채팅 기반 제작 흐름, 소스 내보내기, 배포와 호스팅, 맞춤 도메인, 스냅샷, 롤백, 계획 모드에 이 테스트를 요구하세요. 이런 기능이 있다는 사실만으로 접근 통제를 추정해서는 안 됩니다.

계약과 출시 과정도 통제를 지켜야 합니다

계약과 운영 절차는 잘 다듬어진 평가 테넌트가 사라진 뒤에도 테스트한 통제를 유지해야 합니다. 필수 기능, 적용 요금제, 보존 기간, 전달 한도, 데이터 위치, 지원 접근 규칙, 내보내기 형식, 호환되지 않는 스키마 변경 통지, 필수 통제가 작동하지 않을 때의 구제책을 문서화하세요.

보안 문서는 각 작업을 누가 소유하는지 밝혀야 합니다. 고객은 대개 ID 공급자 그룹, 역할 할당, 승인 정책, 자격 증명 범위, 로그 대상, 보존을 설정합니다. 공급업체는 강제, 플랫폼 관리자 통제, 이벤트 생성, 서비스 격리, 지원 접근 기록을 맡습니다. 소유권이 모호하면 사고 중에 예상 가능한 빈틈이 생깁니다.

권한 의미를 바꾸는 변경에는 통지와 검토를 요구하세요. 새 에이전트 도구, 배포 대상, 연동 유형, 관리자 권한은 고객의 할당 변경 없이도 기존 역할을 넓힐 수 있습니다. 공급업체는 새 권한을 문서화하고 광범위한 맞춤 역할에 조용히 넣지 않아야 합니다.

비프로덕션 신원, 정책, 자격 증명 교환, 승인, 감사 전달이 실패 상황에서도 동작한 뒤에만 프로덕션을 출시하세요. 테스트한 정책 버전을 고정하고, 권한 매트릭스를 보관하며, 접근 검토와 비상 계정의 소유자를 지정하세요. 조직 전체에 적용되는 달력을 받아들이지 말고 조직의 위험과 인력 이직률에 맞춰 검토 주기를 정합니다.

접근 검토에서는 실효 권한, 비활성 계정, 그룹을 우회하는 직접 권한, 사용하지 않는 워크로드 신원, 오래된 자격 증명, 비상 접근, 실패한 감사 전달, 지원 활동을 살펴야 합니다. 검토자는 부여된 권한에 여전히 소유자와 목적이 있다는 증거가 필요합니다. 리소스 범위가 없는 역할 이름 스프레드시트로는 이 질문에 답할 수 없습니다.

한 가지 승인 조건은 절대 바꾸지 마세요. ID 소스가 높은 권한 사용자를 정지하면 프로덕션으로 가는 모든 사용 가능한 경로가 합의된 시간 안에 닫히고, 내보낸 이벤트가 이를 증명해야 합니다. 워크스페이스가 이 테스트를 통과하지 못한다면 나머지 통제 목록은 장식에 불과합니다.