IT 규정 준수를 위한 위험 관리 워크플로

전체 예제: 과도한 권한 부여 액세스 위험

규정 준수 관리자인 Sarah와 위험 담당자인 Maria가 최소 권한 요구 사항에 대한 정책을 위협하는 규정 준수 위험을 식별하고 관리하는 방법을 따르십시오.

1단계: 위험 식별 및 등록

Sarah가 리스크 시나리오 라이브러리를 열어 액세스 제어 위험에 대한 템플릿을 찾습니다. 다른 조직의 유사한 위험을 기반으로 표준화된 설명과 제안된 가능성/효과 등급을 제공하는 민감한 데이터에 대한 과도한 권한 부여 액세스 시나리오를 선택합니다.

시나리오 템플릿을 기반으로 고객 데이터에 대한 과도한 권한 부여 액세스라는 규정 준수 위험을 만듭니다. 위험은 IT 직원이 프로덕션 시스템의 과도한 권한으로 인해 고객 데이터에 무단으로 액세스할 수 있는 위협을 설명합니다.

Sarah가 IT 디렉터 Maria를 위험 담당자로 할당합니다. Maria는 경감 조치가 적용되고 위험이 구체화되면 대처할 책임이 있습니다.

Sarah는 위험 범주를 액세스 제어로 설정하고 상태를 식별됨으로 설정합니다. 위험은 아직 평가되거나 점수화되지 않았습니다.

2단계: 위험 범위 정의

Sarah는 위험 범위 레코드를 만들어 위험 요소와 위험 범위를 보호하는 보안 조치를 정의합니다. 접속 레코드를 사용하여 추적 가능한 링크를 만듭니다.

• 비즈니스 프로세스 매핑: 고객 데이터 처리 비즈니스 운영 프로세스에 위험을 연결합니다. 이 매핑은 위험이 위협하는 운영 워크플로를 보여줍니다.
• 위험 범위 유형: 위험 범위를 분류하는 위험 범위 유형을 사용하여 위험 범위를 적용합니다(예: CMDB에서 추적된 프로덕션 AWS 계정을 가리키는 구성 항목 위험 범위 유형). 적절한 위험 범위 유형이 없는 경우 Sarah가 먼저 만듭니다. IT 규정 준수에 대한 위험 범위 정의 및 적용을 참조하십시오.
• 정책 매핑: 위험을 데이터 액세스 정책에 연결합니다. 최소 권한 정책 절이 있는 RBAC입니다. 위험은 내부 정책을 위반할 수 있습니다.
• 자산 매핑: CMDB에서 자산으로 추적된 프로덕션 AWS 계정에 위험을 연결합니다. 이 매핑은 취약한 특정 시스템을 보여줍니다.
• 매핑 제어: RBAC 적용 검사 제어 버전에 위험을 연결합니다. 이 제어는 액세스 권한이 작업 기능과 일치하는지 확인하여 위험을 완화하기 위해 고안되었습니다. 컨트롤이 올바르게 작동하면 위험에 미치는 영향이 80% 줄어듭니다.

3단계: 위험 평가

Sarah가 규정 준수 위험 평가를 만들어 위험을 공식적으로 평가합니다. 평가 날짜를 현재 날짜로 설정하고 메서드를 이해당사자 설문 조사로 설정합니다.

Sarah는 Salesforce 설문 조사를 사용하여 규정 준수 위험 평가를 만듭니다. 설문 조사는 다음 두 가지 핵심 질문을 포함합니다.

• 가능성: "여러 권한이 있는 액세스 권한으로 인해 IT 직원이 고객 데이터에 대한 무단 액세스 권한을 부여받을 가능성은 어느 정도입니까?" (배율: 1 = 매우 낮음, 5 = 매우 높음)
• 영향: "권한이 없는 액세스가 발생하는 경우 고객 Trust, 규정 준수 및 비즈니스 운영에 미치는 영향은 얼마나 심각합니까?" (배율: 1 = 매우 낮음, 5 = 매우 높음)

Sarah는 Maria(IT 디렉터) 및 CISO, 클라우드 인프라 책임자, 규정 준수 관리자와 같은 세 가지 이해당사자에게 설문 조사를 보냅니다. 각 이해당사자는 설문 조사 링크가 포함된 이메일 알림을 수신합니다.

모든 이해당사자가 평가를 완료합니다. 평균 가능성 등급은 3(중간)이고 평균 영향 등급은 4(높음)입니다.

4단계: 위험 점수 계산

모든 이해당사자가 설문 조사 응답을 제출한 후 Sarah는 집계된 사용자 의견을 검토하고 비즈니스 규칙 엔진을 사용하여 위험 점수를 계산합니다.

내재적인 위험은 적용되지 않은 위험의 자연적 심각도입니다. 수식은 다음과 같습니다. Inherent Risk = Likelihood × Impact

설문 조사 결과를 기반으로 기본 위험 점수는 높은 범위(10~15)에 속하는 12으로 계산됩니다. 이는 제어 기능이 없으면 과도한 권한 부여 액세스 위험이 조직에 상당한 위험을 야기한다는 의미입니다.

잔차 위험은 제어가 적용된 후 남아 있는 심각도입니다. 수식은 Residual Risk = Inherent Risk × (1 - Control Effectiveness)입니다.

RBAC 적용 검사 제어는 80% 효과 등급이 있는 위험과 연결되어 있습니다. 계산된 잔차 위험 점수 2.4는 낮은 범위(0~5)에 속합니다. 이는 RBAC 제어가 위험을 높음에서 낮음으로 효과적으로 줄이는 것을 의미합니다.

Sarah는 규정 준수 위험 평가 레코드에 점수를 모두 기록하고 레코드 상태를 완료됨으로 업데이트합니다.

5단계: AI 생성 위험 요약 검토

Sarah는 위험 요약을 생성하여 위험 요인 및 점수 매기기 근거를 설명하는 AI 기반 설명을 만듭니다. 요약에서는 정기 감사에서 과도한 권한을 감지한 세 가지 위험 요인을 식별하며, 프로덕션 시스템에 규정 준수에 적용되는 중요한 데이터가 포함되어 있으며, 클라우드 인프라 증가로 인해 수동 감사가 더 어려워집니다.

요약에 RBAC 제어의 80% 효율성이 테스트 내역(10개 중 8개에서 통과)을 반영하고 분기별 테스트 및 지속적인 모니터링을 계속하는 것이 좋습니다. 잔차 위험은 낮으므로 즉각적인 치료가 필요하지 않습니다.

6단계: 연속 모니터링 및 히트 맵

Sarah는 백그라운드 모니터링 에이전트를 구성하여 신규 사용자, IAM 역할 변경, 테스트 실패 제어를 감시합니다. 감지되면 에이전트가 새 위험 평가를 트리거하고 Maria에게 알립니다.

Sarah는 위험 히트 맵 대시보드에서 위험을 검토합니다. 히트 맵은 가능성 및 영향별로 위험을 표시하며, 제어가 위협을 효과적으로 완화하고 있음을 나타내는 잔차 위험 점수 2.4를 기반으로 과도한 권한 부여 액세스 위험을 낮음(녹색)으로 색상으로 구분합니다.

7단계: 실패 트리거 제어 동적 위험 업데이트

2분기 동안 RBAC 컨트롤이 분기별 테스트에 실패했습니다. 세 명의 사용자에게는 액세스 권한이 과도합니다.

시스템에서 다음 위험을 자동으로 업데이트합니다.

• 제어 효율이 0%로 떨어짐
• 잔차 위험 재계산: 12 × (1 - 0.00) = 12 (High)
• Maria에게 잔차 위험이 2.4에서 12으로 증가했다는 경고 수신
• 히트 맵이 녹색에서 빨간색으로 변경됨
• 백그라운드 에이전트에서 규정 준수 확인 만들기

8단계: 위험 처리 계획

Sarah는 액세스 권한 수정 템플릿을 사용하여 위험 처리 계획을 만듭니다. 템플릿에는 액세스 권한 검토, 과도한 권한 취소, 문서 변경, 테스트 재실행, 증거 업로드를 위한 과업이 포함되어 있습니다.

Maria의 팀이 조치를 완료합니다. 재테스트가 통과되면:

• 효율성 복원을 80%로 제어
• 잔차 위험 재계산: 12 × (1 - 0.80) = 2.4 (Low)
• Maria가 위험이 12개에서 2.4개로 감소했다는 확인을 받음
• 히트 맵이 녹색으로 되돌아감

Sarah가 치료 계획을 마감하고 위험 상태를 완화됨으로 표시합니다.

위험 계층 및 상위-하위 관계

하나의 상위 수준 위험이 여러 하위 위험을 롤업하는 상위-하위 관계를 설정합니다. 예를 들어 전역 데이터 센터 보안 취약성이라는 상위 위험은 특정 서버(서버 A의 오래된 OS) 및 방화벽(범위방화벽의 만료된 TLS 인증서)의 하위 위험에 연결될 수 있습니다.

하위 위험 점수가 상위 항목에 자동으로 롤업됩니다. 경영진은 IT 팀이 특정 시스템을 드릴다운하는 동안 집계된 점수를 볼 수 있습니다. 제어 실패로 인해 하위 위험 점수가 증가하면 상위 위험 점수가 자동으로 업데이트됩니다.