우리는 역할 기반 액세스 제어 모델을 구축하고 있습니다. XNUMX부, 준비

저는 현재 소프트웨어 공급업체, 특히 액세스 제어 솔루션에서 일하고 있습니다. 그리고 "전생의"경험은 대규모 금융 조직인 고객 측과 연결되어 있습니다. 당시 우리 정보보안부 접근통제그룹은 IdM에 있어서 큰 역량을 자랑할 수 없었습니다. 우리는 그 과정에서 많은 것을 배웠고, 회사의 정보 시스템에서 사용자 권한을 관리하기 위한 작업 메커니즘을 구축하기 위해 많은 어려움을 겪어야 했습니다.

제가 힘들게 얻은 고객 경험과 공급업체 지식 및 역량을 결합하여 본질적으로 단계별 지침을 공유하고 싶습니다. 즉, 대기업에서 역할 기반 액세스 제어 모델을 만드는 방법과 이것이 결과적으로 제공할 사항입니다. . 내 지침은 두 부분으로 구성됩니다. 첫 번째는 모델 구축을 준비하는 것이고, 두 번째는 실제로 구축하는 것입니다. 다음은 첫 번째 부분, 즉 준비 부분입니다.

NB 불행히도 롤모델을 구축하는 것은 결과가 아니라 과정입니다. 또는 오히려 회사에서 액세스 제어 생태계를 만드는 프로세스의 일부일 수도 있습니다. 그러니 오랫동안 게임을 준비하십시오.

먼저 정의해 보겠습니다. 역할 기반 액세스 제어란 무엇입니까? 수만 또는 수십만 명의 직원(엔티티)이 있는 대형 은행이 있고 각 직원(엔티티)은 수백 개의 내부 은행 정보 시스템(객체)에 대한 수십 개의 액세스 권한을 가지고 있다고 가정합니다. 이제 개체 수에 주체 수를 곱합니다. 이는 먼저 구축하고 제어하는 ​​데 필요한 최소 연결 수입니다. 이 작업을 수동으로 수행하는 것이 실제로 가능합니까? 물론 그렇지 않습니다. 역할은 이 문제를 해결하기 위해 만들어졌습니다.

역할은 사용자 또는 사용자 그룹이 특정 작업을 수행하는 데 필요한 권한 집합입니다. 각 직원은 하나 이상의 역할을 가질 수 있으며, 각 역할에는 해당 역할 내의 사용자에게 허용되는 하나 이상의 권한이 포함될 수 있습니다. 역할은 직원의 특정 직위, 부서 또는 기능적 작업과 연결될 수 있습니다.

역할은 일반적으로 각 정보 시스템의 개별 직원 인증을 통해 생성됩니다. 그런 다음 각 시스템의 역할로 글로벌 비즈니스 역할이 형성됩니다. 예를 들어, 비즈니스 역할 "신용 관리자"에는 은행 고객 사무실에서 사용되는 정보 시스템의 여러 개별 역할이 포함됩니다. 예를 들어, 주요 자동화 뱅킹 시스템, 현금 모듈, 전자 문서 관리 시스템, 서비스 관리자 등이 있습니다. 일반적으로 비즈니스 역할은 조직 구조, 즉 회사 부서 및 직위 집합과 연결되어 있습니다. 이것이 글로벌 역할 매트릭스가 형성되는 방식입니다 (아래 표에 예가 나와 있습니다).

상업 구조에서 각 직위의 직원에게 필요한 모든 권리를 제공하는 100% 역할 모델을 구축하는 것은 불가능하다는 점은 주목할 가치가 있습니다. 예, 그럴 필요는 없습니다. 결국, 역할 모델은 끊임없이 변화하는 환경에 의존하기 때문에 정적인 것이 될 수 없습니다. 그리고 회사의 비즈니스 활동이 변경되어 조직 구조와 기능이 변경됩니다. 그리고 자원의 완전한 제공 부족, 직무 설명 미준수, 안전을 희생하면서 이익을 얻으려는 욕구 및 기타 여러 요인으로 인해 발생합니다. 따라서 직위에 배정될 때 필요한 기본권한에 대한 사용자의 요구를 최대 80%까지 커버할 수 있는 역할모델을 구축하는 것이 필요하다. 그리고 필요한 경우 나중에 별도의 신청을 통해 나머지 20%를 요청할 수도 있습니다.

물론 “100% 롤모델은 없나요?”라고 물을 수도 있습니다. 예를 들어 일부 연구 기관에서 자주 변경되지 않는 비영리 구조에서 이런 일이 발생하는 이유는 무엇입니까? 또는 안전이 최우선인 보안 수준이 높은 군산복합체 조직에서도 마찬가지입니다. 이는 상업적 구조에서 발생하지만 별도의 부서의 틀 내에서 이루어지며 그 작업은 상당히 정적이고 예측 가능한 프로세스입니다.

역할 기반 관리의 주요 장점은 정보 시스템 사용자 수에 비해 역할 수가 훨씬 적기 때문에 권한 발급이 단순화된다는 것입니다. 그리고 이는 모든 산업에 해당됩니다.

소매 회사를 예로 들어 보겠습니다. 이 회사는 수천 명의 영업사원을 고용하고 있지만 시스템 N에서 동일한 권한 세트를 갖고 있으며 이들에게는 단 하나의 역할만 생성됩니다. 새로운 영업사원이 회사에 들어오면 자동으로 필요한 모든 권한을 갖춘 시스템에서 필요한 역할이 자동으로 할당됩니다. 또한 한 번의 클릭으로 수천 명의 판매자에 대한 권리를 한 번에 변경할 수 있습니다. 예를 들어 보고서 생성을 위한 새 옵션을 추가할 수 있습니다. 각 계정에 새로운 권한을 연결하는 수천 가지 작업을 수행할 필요가 없습니다. 역할에 이 옵션을 추가하기만 하면 모든 판매자에게 동시에 표시됩니다.

역할 기반 관리의 또 다른 장점은 호환되지 않는 인증 발급이 필요 없다는 것입니다. 즉, 시스템에서 특정 역할을 맡은 직원은 동시에 다른 역할을 가질 수 없으며 해당 권한은 첫 번째 권한과 결합되어서는 안됩니다. 눈에 띄는 예는 금융 거래의 입력 기능과 통제 기능을 결합하는 것을 금지하는 것입니다.

역할 기반 액세스 제어가 어떻게 탄생했는지에 관심이 있는 사람은 누구나 할 수 있습니다.
역사 속으로 뛰어들다
역사를 살펴보면 IT 커뮤니티는 70세기 XNUMX년대에 처음으로 액세스 제어 방법을 생각했습니다. 그 당시에는 애플리케이션이 매우 단순했지만 지금과 마찬가지로 누구나 애플리케이션에 대한 액세스를 편리하게 관리하고 싶어했습니다. 사용자 권한 부여, 변경 및 제어 - 각 사용자가 어떤 액세스 권한을 갖고 있는지 더 쉽게 이해할 수 있도록 하기 위한 것입니다. 그러나 당시에는 공통 표준이 없었고 최초의 출입 통제 시스템이 개발 중이었고 각 회사는 자체 아이디어와 규칙을 기반으로 했습니다.

현재 다양한 액세스 제어 모델이 알려져 있지만 즉시 나타나지는 않았습니다. 이 분야의 발전에 크게 기여한 사람들에 대해 이야기합시다.

첫 번째이자 아마도 가장 간단한 모델은 다음과 같습니다. 임의(선택적) 액세스 제어 (DAC - 임의 액세스 제어). 이 모델은 액세스 프로세스의 모든 참가자가 권리를 공유한다는 것을 의미합니다. 각 사용자는 특정 개체나 작업에 액세스할 수 있습니다. 본질적으로 여기서 권리 주체의 집합은 객체의 집합에 해당합니다. 이 모델은 너무 유연하고 유지 관리가 너무 어려운 것으로 나타났습니다. 액세스 목록은 결국 거대해지고 제어하기 어려워졌습니다.

두 번째 모델은 강제 접근 제어(MAC - Mandatory access control). 이 모델에 따르면 각 사용자는 특정 수준의 데이터 기밀성에 대해 발급된 액세스 권한에 따라 개체에 대한 액세스 권한을 받습니다. 따라서 객체는 기밀성 수준에 따라 분류되어야 합니다. 첫 번째 유연한 모델과 달리 이 모델은 너무 엄격하고 제한적인 것으로 나타났습니다. 회사에 다양한 정보 리소스가 있는 경우에는 그 사용이 정당화되지 않습니다. 다양한 리소스에 대한 액세스를 차별화하려면 중복되지 않는 많은 범주를 도입해야 합니다.

이 두 가지 방법의 명백한 불완전성으로 인해 IT 커뮤니티는 다양한 유형의 조직 액세스 제어 정책을 지원하기 위해 보다 유연하고 동시에 다소 보편적인 모델을 계속 개발해 왔습니다. 그러다가 등장했지 세 번째 역할 기반 액세스 제어 모델! 이 접근 방식은 사용자 신원에 대한 인증뿐만 아니라 시스템 내 운영 기능도 필요하기 때문에 가장 유망한 것으로 입증되었습니다.

처음으로 명확하게 설명된 역할 모델 구조는 1992년 미국 국립 표준 기술 연구소(National Institute of Standards and Technology)의 미국 과학자 David Ferrailo와 Richard Kuhn이 제안했습니다. 그러다가 처음으로 용어가 등장했습니다. RBAC(역할 기반 액세스 제어). 주요 구성 요소와 그 관계에 대한 이러한 연구와 설명은 INCITS(국제 정보 기술 표준 위원회)의 승인을 받아 오늘날에도 여전히 유효한 INCITS 359-2012 표준의 기초를 형성했습니다.

표준에서는 역할을 "역할에 할당된 사용자에게 할당된 권한 및 책임과 관련하여 일부 관련 의미를 갖는 조직의 맥락에서 직무 기능"으로 정의합니다. 이 문서는 사용자, 세션, 역할, 권한, 작업 및 개체뿐만 아니라 이들 간의 관계 및 상호 연결과 같은 RBAC의 기본 요소를 설정합니다.

표준은 역할 모델을 구축하는 데 필요한 최소한의 구조를 제공합니다. 즉, 권한을 역할에 결합한 다음 이러한 역할을 통해 사용자에게 액세스 권한을 부여하는 것입니다. 개체와 작업에서 역할을 구성하는 메커니즘이 설명되고, 역할의 계층 구조와 권한 상속이 설명됩니다. 결국 어느 회사에는 회사의 모든 직원에게 필요한 기본 권한을 통합하는 역할이 있습니다. 이는 이메일, EDMS, 기업 포털 등에 대한 액세스일 수 있습니다. 이러한 권한은 "직원"이라는 하나의 일반 역할에 포함될 수 있으며 각 상위 수준 역할에서 모든 기본 권한을 반복해서 나열할 필요가 없습니다. 단순히 "직원" 역할의 상속 특성을 나타내는 것으로 충분합니다.

나중에 표준은 끊임없이 변화하는 환경과 관련된 새로운 액세스 속성으로 보완되었습니다. 정적 및 동적 제한을 도입하는 기능이 추가되었습니다. 정적은 역할 결합이 불가능함을 의미합니다(위에서 언급한 것과 동일한 입력 및 작업 제어). 동적 제한은 시간(근무/비근무 시간 또는 요일), 위치(사무실/집) 등과 같은 매개변수를 변경하여 결정할 수 있습니다.

별도로, 그것에 대해 말해야합니다. 속성 기반 액세스 제어(ABAC - 속성 기반 액세스 제어). 이 접근 방식은 속성 공유 규칙을 사용하여 액세스 권한을 부여하는 것을 기반으로 합니다. 이 모델은 별도로 사용될 수 있지만 고전적인 역할 모델을 적극적으로 보완하는 경우가 많습니다. 사용자, 리소스, 장치의 속성은 물론 시간이나 위치도 특정 역할에 추가될 수 있습니다. 이를 통해 더 적은 수의 역할을 사용하고 추가 제한을 도입하며 액세스를 최대한 최소화하여 보안을 향상시킬 수 있습니다.

예를 들어 회계사가 특정 지역에서 근무하는 경우 계정에 대한 액세스가 허용될 수 있습니다. 그런 다음 전문가의 위치가 특정 참조 값과 비교됩니다. 또는 사용자가 허용된 장치 목록에 포함된 장치에서 로그인하는 경우에만 계정에 대한 액세스 권한을 부여할 수 있습니다. 역할 모델에 대한 좋은 추가 기능이지만 많은 규칙과 권한 또는 제한 테이블을 만들어야 하기 때문에 자체적으로는 거의 사용되지 않습니다.

내 "전생"에서 ABAC를 사용한 예를 들어 보겠습니다. 우리 은행에는 여러 지점이 있었습니다. 이들 지점의 고객 사무실 직원은 정확히 동일한 작업을 수행했지만 해당 지역의 계정으로만 기본 시스템에서 작업해야 했습니다. 먼저, 우리는 각 지역에 대해 별도의 역할을 만들기 시작했습니다. 반복되는 기능을 갖고 있지만 다른 계정에 액세스할 수 있는 역할이 너무 많았습니다! 그런 다음 사용자의 위치 속성을 사용하고 이를 검토할 특정 계정 범위와 연결하여 시스템의 역할 수를 크게 줄였습니다. 결과적으로 역할은 하나의 지점에만 남아 있었고 은행의 다른 모든 지역 부서의 해당 직위에 대해 복제되었습니다.

이제 필요한 준비 단계에 대해 이야기해 보겠습니다. 이 단계 없이는 실무 역할 모델을 구축하는 것이 불가능합니다.

1단계. 기능 모델 생성

각 부서와 직위의 기능을 자세히 설명하는 최상위 문서인 기능 모델을 만드는 것부터 시작해야 합니다. 일반적으로 정보는 부서, 부문, 부서와 같은 개별 단위에 대한 직무 설명 및 규정과 같은 다양한 문서에서 입력됩니다. 기능 모델은 모든 관심 부서(비즈니스, 내부 통제, 보안)와 합의하고 회사 경영진의 승인을 받아야 합니다. 이 문서는 무엇을 위한 것입니까? 롤모델이 참고할 수 있도록 말이죠. 예를 들어, 직원의 기존 권리를 기반으로 시스템에서 제거되고 "공통 분모로 축소"된 역할 모델을 구축할 것입니다. 그런 다음 시스템의 비즈니스 소유자와 수신된 역할에 동의할 때 특정 권한이 역할에 포함되는 기능 모델의 특정 지점을 참조할 수 있습니다.

2단계. IT 시스템을 감사하고 우선순위 계획을 수립합니다.

두 번째 단계에서는 IT 시스템에 대한 감사를 수행하여 시스템에 대한 액세스가 어떻게 구성되어 있는지 이해해야 합니다. 예를 들어 제가 다니던 금융회사는 수백 개의 정보 시스템을 운영했습니다. 모든 시스템에는 역할 기반 관리의 기초가 있었고 대부분은 몇 가지 역할을 갖고 있었지만 대부분 종이나 시스템 디렉터리에 있었습니다. 오래 전부터 사용되었으며 이에 대한 액세스는 실제 사용자 요청에 따라 허용되었습니다. 당연히 수백 개의 시스템에서 동시에 역할 모델을 구축하는 것은 불가능하며 어딘가에서 시작해야 합니다. 우리는 성숙도 수준을 결정하기 위해 액세스 제어 프로세스에 대한 심층 분석을 수행했습니다. 분석 과정에서 중요도, 준비 상태, 폐기 계획 등 정보 시스템의 우선 순위를 정하는 기준이 개발되었습니다. 그들의 도움으로 우리는 이러한 시스템에 대한 역할 모델의 개발/업데이트를 준비했습니다. 그런 다음 액세스 제어를 자동화하기 위해 ID 관리 솔루션과의 통합 계획에 역할 모델을 포함시켰습니다.

그렇다면 시스템의 중요성을 어떻게 결정합니까? 다음 질문에 답해 보세요.

• 시스템이 회사의 핵심 활동이 의존하는 운영 프로세스와 연결되어 있습니까?
• 시스템 중단이 회사 자산의 무결성에 영향을 미치나요?
• 중단 후 활동을 복원할 수 없는 시스템의 최대 허용 가동 중지 시간은 얼마입니까?
• 시스템의 정보 무결성을 위반하면 재정적, 평판 측면에서 돌이킬 수 없는 결과를 초래할 수 있습니까?
• 사기에 대한 중요성. 기능이 제대로 제어되지 않으면 내부/외부 사기 행위로 이어질 수 있습니다.
• 이러한 시스템에 대한 법적 요구 사항과 내부 규칙 및 절차는 무엇입니까? 규정을 준수하지 않을 경우 규제 당국으로부터 벌금을 물게 됩니까?

우리 금융회사에서는 이런 감사를 실시했습니다. 경영진은 최우선 순위 목록에 있는 정보 시스템에서 기존 사용자와 권한을 먼저 살펴보기 위해 액세스 권한 검토 감사 절차를 개발했습니다. 보안 부서가 이 프로세스의 소유자로 지정되었습니다. 그러나 회사의 액세스 권한을 전체적으로 파악하려면 IT 및 비즈니스 부서를 프로세스에 참여시켜야 했습니다. 그리고 여기에서 분쟁, 오해, 때로는 방해 행위까지 시작되었습니다. 아무도 현재 책임에서 벗어나 언뜻보기에 이해할 수 없는 활동에 참여하고 싶어하지 않습니다.

NB IT 프로세스가 개발된 대기업은 아마도 IT 감사 절차인 IT 일반 통제(ITGC)에 익숙할 것입니다. 이를 통해 IT 프로세스의 단점을 식별하고 모범 사례(ITIL, COBIT, IT)에 따라 프로세스를 개선하기 위한 통제를 확립할 수 있습니다. 거버넌스 등) 이러한 감사를 통해 IT와 비즈니스는 서로를 더 잘 이해하고 공동 개발 전략을 개발하고, 위험을 분석하고, 비용을 최적화하고, 보다 효과적인 업무 접근 방식을 개발할 수 있습니다.



감사 영역 중 하나는 정보 시스템에 대한 논리적 및 물리적 액세스 매개변수를 결정하는 것입니다. 우리는 얻은 데이터를 역할 모델 구축에 추가로 사용할 기초로 삼았습니다. 이 감사 결과, 우리는 기술 매개변수가 결정되고 설명이 제공되는 IT 시스템 등록을 갖게 되었습니다. 또한 각 시스템에 대해 해당 시스템을 운영하는 비즈니스 방향에 따라 소유자가 식별되었습니다. 즉, 이 시스템이 제공하는 비즈니스 프로세스를 담당하는 사람이 바로 소유자였습니다. 특정 IS에 대한 비즈니스 요구 사항의 기술 구현을 담당하는 IT 서비스 관리자도 임명되었습니다. 회사에 가장 중요한 시스템과 그 기술 매개 변수, 시운전 및 해체 조건 등이 기록되었으며 이러한 매개 변수는 롤 모델 생성을 준비하는 과정에서 매우 도움이 되었습니다.

3단계 방법론 만들기

모든 사업의 성공의 열쇠는 올바른 방법입니다. 따라서 역할 모델을 구축하고 감사를 수행하려면 부서 간의 상호 작용을 설명하고 회사 규정에 책임을 설정하는 등의 방법론을 만들어야 합니다.
먼저 액세스 및 권한 부여 절차를 확립하는 사용 가능한 모든 문서를 검토해야 합니다. 좋은 방법으로 프로세스는 여러 수준에서 문서화되어야 합니다.

• 일반 기업 요구 사항;
• 정보 보안 영역에 대한 요구 사항(조직 활동 영역에 따라 다름)
• 기술 프로세스 요구 사항(지침, 액세스 매트릭스, 지침, 구성 요구 사항)

우리 금융 회사에서는 오래된 문서를 많이 발견했으며, 구현되는 새로운 프로세스에 따라 이를 가져와야 했습니다.

관리 명령에 따라 보안, IT, 비즈니스 및 내부 통제 담당자를 포함하는 실무 그룹이 만들어졌습니다. 이 명령에는 그룹 창설 목표, 활동 방향, 존재 기간 및 각 측의 책임자가 설명되어 있습니다. 또한 우리는 감사 방법론과 역할 모델 구축 절차를 개발했습니다. 이는 해당 분야의 모든 책임 대표자들이 동의하고 회사 경영진의 승인을 받았습니다.

업무 수행 절차, 기한, 책임 등을 설명하는 문서 -처음에는 모든 사람에게 명확하지 않은 소중한 목표를 달성하는 과정에서 누구도 "우리가 이 일을 하는 이유, 왜 필요한지 등"에 대해 질문하지 않을 것이라는 보장입니다. 프로세스를 "도약"하거나 속도를 늦출 기회가 없습니다.

4단계. 기존 액세스 제어 모델의 매개변수 수정

우리는 접근 통제 측면에서 소위 "시스템 여권"을 작성하고 있습니다. 본질적으로 이것은 액세스를 제어하기 위한 모든 알고리즘을 기록하는 특정 정보 시스템에 대한 설문지입니다. 이미 IdM급 솔루션을 구현한 회사는 시스템 연구가 시작되는 곳이기 때문에 이러한 설문지에 익숙할 것입니다.

시스템 및 소유자에 대한 일부 매개변수가 IT 레지스트리의 설문지로 유입되었지만(2단계 감사 참조) 새로운 매개변수도 추가되었습니다.

• 계정 관리 방법(데이터베이스에서 직접 또는 소프트웨어 인터페이스를 통해)
• 사용자가 시스템에 로그인하는 방법(별도 계정 사용 또는 AD 계정, LDAP 등 사용)
• 사용되는 시스템에 대한 액세스 수준(응용 프로그램 수준, 시스템 수준, 네트워크 파일 리소스의 시스템 사용)
• 시스템이 실행되는 서버의 설명 및 매개변수
• 지원되는 계정 관리 작업(차단, 이름 변경 등)
• 시스템 사용자 식별자를 생성하는 데 사용되는 알고리즘이나 규칙은 무엇입니까?
• 인사 시스템에서 직원의 기록(성명, 직원 번호 등)과의 연결을 설정하는 데 사용할 수 있는 속성은 무엇입니까?
• 가능한 모든 계정 속성 및 이를 작성하기 위한 규칙
• 시스템에 어떤 액세스 권한이 있는지(역할, 그룹, 원자 권한 등이 중첩되거나 계층적 권한인지)
• 액세스 권한을 분할하는 메커니즘(직위, 부서, 기능 등)
• 시스템에 권리 분리(SOD – Segregation of Duties)에 대한 규칙이 있고 어떻게 작동합니까?
• 부재, 전근, 해고, 직원 데이터 업데이트 등의 이벤트가 시스템에서 처리되는 방식.

이 목록은 액세스 제어 프로세스와 관련된 다양한 매개변수 및 기타 개체를 자세히 설명하면서 계속될 수 있습니다.

5단계. 비즈니스 중심의 권한 설명 작성

역할 모델을 구축할 때 필요한 또 다른 문서는 그 뒤에 있는 비즈니스 기능에 대한 자세한 설명과 함께 정보 시스템에서 사용자에게 부여할 수 있는 모든 가능한 권한(권리)에 대한 참고서입니다. 종종 시스템의 권한은 문자와 숫자로 구성된 특정 이름으로 암호화되어 있으며 비즈니스 직원은 이러한 기호 뒤에 무엇이 있는지 알아낼 수 없습니다. 그런 다음 IT 서비스로 이동합니다. 예를 들어 거의 사용되지 않는 권한에 대한 질문에도 대답할 수 없습니다. 그런 다음 추가 테스트를 수행해야 합니다.

이미 비즈니스 설명이 있거나 이러한 권한이 그룹 및 역할에 조합되어 있는 경우에도 좋습니다. 일부 애플리케이션의 경우 개발 단계에서 이러한 참조를 생성하는 것이 가장 좋습니다. 하지만 이런 일은 자주 발생하지 않으므로 다시 IT 부서에 가서 가능한 모든 권리에 대한 정보를 수집하고 설명합니다. 우리 가이드에는 궁극적으로 다음 내용이 포함됩니다.

• 접근 권한이 적용되는 객체를 포함한 기관의 이름
• 개체에 대해 수행할 수 있는 작업(예: 지역별 또는 클라이언트 그룹별 제한 가능성 보기, 변경 등)
• 인증 코드(인증을 사용하여 실행할 수 있는 시스템 기능/요청의 코드 및 이름)
• 권한에 대한 설명(권한을 적용할 때 IS의 조치에 대한 자세한 설명과 프로세스에 대한 결과)
• 권한 상태: "활성"(권한이 최소한 한 명의 사용자에게 할당된 경우) 또는 "비활성"(권한이 사용되지 않는 경우).

6단계 시스템에서 사용자 및 권리에 대한 데이터를 다운로드하고 이를 인사 소스와 비교합니다.

준비의 마지막 단계에서는 정보 시스템에서 모든 사용자와 이들이 현재 갖고 있는 권리에 대한 데이터를 다운로드해야 합니다. 여기에는 두 가지 가능한 시나리오가 있습니다. 첫째, 보안 부서는 시스템에 직접 접근할 수 있고 관련 보고서를 다운로드할 수 있는 수단을 갖고 있는데, 이는 자주 발생하지는 않지만 매우 편리합니다. 둘째, 필요한 형식으로 보고서를 받도록 IT에 요청을 보냅니다. 경험상 처음부터 IT와 합의하여 필요한 데이터를 얻는 것은 불가능합니다. 정보가 원하는 형식과 형식으로 수신될 때까지 여러 가지 접근 방식을 취하는 것이 필요합니다.

다운로드해야 하는 데이터:

• 계정 이름
• 할당된 직원의 이름
• 상태(활성 또는 차단됨)
• 계정 생성 날짜
• 마지막 사용 날짜
• 사용 가능한 권한/그룹/역할 목록

따라서 우리는 모든 사용자와 그들에게 부여된 모든 권리를 가지고 시스템에서 다운로드를 받았습니다. 그리고 역할 모델 구축 작업은 활성 사용자에 대해서만 수행되므로 차단된 모든 계정을 즉시 따로 보관합니다.

그런 다음 회사에 해고된 직원에 대한 액세스를 차단하는 자동화된 수단이 없거나(종종 발생함) 패치워크 자동화가 항상 올바르게 작동하지 않는 경우 모든 "죽은 영혼"을 식별해야 합니다. 우리는 이미 해고되었지만 어떤 이유로든 권리가 차단되지 않은 직원의 계정에 대해 이야기하고 있습니다. 차단해야 합니다. 이를 위해 업로드된 데이터를 인사 소스와 비교합니다. 인력 하역 역시 인력 데이터베이스를 관리하는 부서로부터 사전에 입수해야 합니다.

이와 별도로 개인 데이터베이스에서 소유자가 발견되지 않고 누구에게도 할당되지 않은 즉, 소유자가 없는 계정을 별도로 설정해야 합니다. 이 목록을 사용하려면 마지막 사용 날짜가 필요합니다. 아주 최근인 경우에도 소유자를 찾아야 합니다. 여기에는 누구에게도 할당되지 않지만 모든 프로세스와 연결된 외부 계약자의 계정 또는 서비스 계정이 포함될 수 있습니다. 해당 계정이 누구에게 속해 있는지 확인하려면 모든 부서에 응답을 요청하는 편지를 보낼 수 있습니다. 소유자가 발견되면 해당 데이터를 시스템에 입력합니다. 이렇게 하면 모든 활성 계정이 식별되고 나머지는 차단됩니다.

업로드에서 불필요한 기록이 제거되고 활성 계정만 남게 되면 특정 정보 시스템에 대한 역할 모델 구축을 시작할 수 있습니다. 하지만 이에 대해서는 다음 기사에서 말씀드리겠습니다.

저자: Lyudmila Sevastyanova, Solar inRights 프로모션 관리자

출처 : habr.com