Microsoft Entra Privileged Identity Management 이란?
한줄평
Microsoft Entra Privileged Identity Management (이하 PIM) 을 한줄로 표현 해보자면 아래와 같다.
Azure와 관련된 권한 관리 서비스
PIM으로 할 수 있는 것들
- Entra ID 권한 및 구독에 대한 권한 부여 (eligible, active 모두)
- eligible일 경우
- 지정된 시간에만 권한 부여 제공
- 시간이 지나면 자동으로 권한 회수
- 리소스 단위로 권한 부여 가능
- 사용하려는 사람의 요청/허가 기반 권한 부여
기존의 권한 부여
지금까지 어떻게 사용해 왔는가?
일을 하다보면 한사람 또는 몇몇의 사람들이 권한들을 가지고 모든 것들을 처리하기는 무리가 있다. 아래와 같은 상황에 대해 생각해보자.
1번 상황
- Azure를 다루는 관리자가 여러명 있는 가운데 운영 환경에서의 권한이 있어야 장애 대처 또는 여러가지 상황에 대한 지원이 가능하다.
- 예를 들어 장애 대처 및 여러 상황에 대비한 권한이 주어져야 한다.
- 이 경우 고민 포인트가
- 과연 권한을 가진 모든 관리자가 실수나 정보 유출로 아니한 권한 오남용이 있을 수 있는건 아닐까?
(잠금을 안하고 화장실을 간다거나?)
(혹시 술한잔 하고 작업하다가 문제가 생기진 않을까?) - 소수의 인원이 많은 권한 혹은 몇몇의 관리자가 변경/수정까지 모두 상시 가능한 상황이 맞는것인가?
- resource 그룹을 착각하고 뭔가 잘못된 작업을 할 수 있는것 아닐까?
- 과연 권한을 가진 모든 관리자가 실수나 정보 유출로 아니한 권한 오남용이 있을 수 있는건 아닐까?
2번 상황
- 프로젝트 팀은 특정 paas형 database에 대한 설정 변경 및 database instance 내의 database 삭제를 위해 리소스에 대한 권한이 필요하다.
- 또는 특정 vm에 Login with Entra ID 같은 기능을 쓰고 있다면, 로그인을 할 수 있는 권한이 해당 유저에게 vm에 대하여 가지고 있어야한다.
- 그럼 여기서 고민 포인트가
- 매번 프로젝트 팀의 프로젝트 기간이 끝난 후, 매달 vm에 대한 수요 조사를 통해 권한을 확인하고 빼는 노력이 필요한데 과연 효율성이 있는 것인가?
- 권한을 보통 몇일 또는 몇주 단위로 가지고 있을 확률이 큰데, 그 기간동안 변경하면 안되는 부분을 변경하는 리스크는 어떻게 관리할 것인가?
(나중에 "이거 하면 안되는 거였나요?" 라며 소 잃고 외양간 고칠 때 가장 힘들다.) - 매번 높은 권한을 긴 기간동안 부여할 때 마다 찝찝함을 뒤로하며 기도 메타로 가는게 맞는건가?
위는 특정한 상황들만 말했지만 위의 리소스에 그 어떤 리소스를 대입해도 이상하지 않다.
즉, 권한을 오래 들고 있으면 그 만큼 human error에 대한 리스크는 커질 수 있다는 뜻이며, 만에 하나 회수가 안되면 잠재적 리스크로 변하게 된다.
기존의 권한 부여 방식을 통해 느낀점
기존의 방식대로 진행하며 느끼게 부분들은 아래와 같다.
- 관리의 규모가 크면 클수록 권한 회수가 힘들다.
- 특정 일시에 작업을 한다고 하면 해당 권한이 특정 시간에만 부여됬다가 알아서 빠졌으면 좋겠다.
- 특정 작업에 대한 허가를 email 또는 메신저로 요청 받아 내가 따로 권한 부여가 아닌, 버튼 하나로 그냥 부여 승인/거부 를 하고 싶다.
- 허가/승인 또는 내용에 대한 내용들이 로깅이 되었으면 좋겠다.
위와 같은 pain point들을 어떻게 해결할 수 있을까?
서비스를 개발/도입 하자!
pain point들은 일반적으로 기도를 한다고 해결되진 않는다. 직접 움직여야 해결이 된다. 크게 개발과 도입 중 하나를 선택할 수 있다.
-
개발
개발 또한 가능한 부분이다. 권한을 부여할 수 있는 서비스 어카운트를 만들어 프론트 만들고 백엔드가 해당 서비스 어카운트를 트리거하여 권한을 부여. 회수도 시간 맞춰 회수.
A to Z 개발은 몇가지 리스크가 있다.- 너무 높은 권한을 가진 서비스 어카운트가 테넌트 또는 구독 내 존재하게 된다. (존재만으로도 부담스럽다.)
- 수 많은 테스트를 통해 악용 또는 남용이 되지 않아야 되며 보안적으로도 신경을 써야 한다.
따라서 결론을 내보자면, 개발은 여러 비용이 많이 들어가기에, 배보다 배꼽이 더 커지는 상황이 발생될 것 같아 보인다.
-
도입
만약 코어한 기능만 갖추어진 서비스를 도입할 수 있다면 가장 베스트이다. 도입은 큰 리스크 보단 어떤 서비스 또는 툴을 고르냐고 문제이다.
많은 툴 및 서비스들 중에 최근에 내가 실제 운영환경에서 사용하고 있는 Microsoft Entra Privileged Identity Management에 대해 기록하려 한다.
실사용기
무엇이 필요하나?
먼저 필요한 부분들을 보자.
최소 Microsoft Entra ID P2 가 필요하다.
어떻게 사용하나?
PIM은 크게 2가지로 나누어져 있다.
위쪽의 빨간 박스 부분이 내가 권한을 신청하거나 허가를 해주는 부분,
아래쪽의 빨간 박스 부분이 관리자로서 해당 권한신청 관련 설정 부분으로 나누어진다.
권한을 신청하기에 앞서 '누구에게 어떤 권한을 신청 가능하게 할까?'를 정할 수 있는 아래 빨간 박스 부분 부터 보고 가보자.
Manage
Entra ID 또는 구독에 관련된 권한들을 설정하고 부여할 수 있다. 또는 특정 그룹에 jit 느낌으로 인원을 넣어줄 수 있다. 이는 라이선스 관련된 부분을 활용하기 좋아보인다.
아래는 'Microsoft Entra roles' 를 눌러 보이는 화면이다.
워낙 방대하기에 메뉴를 하나하나 리뷰하기 보단, 코어한 기능을 위주로 보자.
Entra ID 쪽 권한은 웬만해선 custom role 생성을 권장하지 않는다. (안되는게 많다.) 반대로 구독은 custom role을 생성을 권장한다. 입맛에 맞게 쓰는 즐거움이 있다!! 만들다가 시간이 쏜살같이 흘러간걸 느낄 수 있을것이다.
가장 먼저 해야할 것은 custom role이든 built in role이든 우선 아래와 같이 role 별로 설정을 해주어야 한다.
Settings를 눌러보면,
위의 스크린샷에 나와있는 부분과 같이, (아래 내용들 중 스크린샷에 담기지 않은것들도 포함)
- 최대 몇시간 열릴지?
- activation 될 때 필수로 필요한 것들
- 허가는 누가?
- 어떤 notification을 누구에게?
- eligible 또는 ative assignment를 허용할지? permanent assigment를 허용할지?
- permanent가 아니라면, 해당 role을 어느 기간동안 활용 가능하게 설정할것인지?
role 별 설정이 끝이 났다면, 해당 role을 어떤 형태로 누구에게 할당하는지를 설정해야 한다.
Assignments를 눌러보면,
위와 같이 어떤 그룹에 어떠한 형태로 assign 하였는지 보거나 설정할 수 있다.
Tasks
위와 같은 기능들을 제공한다. 위 기능들을 조금 풀어서 써보자면,
- My roles: 내게 부여된 권한을 확인하고 요청할 때 사용
- My requests: 요청한 권한들을 tracking 할 때 사용
- Approve requests: 내가 허가 해줘야 할 건들에 대해 확인할 때 사용
- Review access: 부여한 엑세스들에 대해 정기적 리뷰할 때 사용
아마 가장 많이 쓰는 부분은, 권한 신청 및 승인이다.
위와 같이 원하는 시간대에 미리 승인 요청을 해놓고 승인자가 approve 한다면 해당 시간에 권한이 부여 되었다가 자동으로 회수된다.
권한을 부여되어야 하는 리소스 또한 세분화해서 요청할 수 있다. approver는 해당 권한 요청이 너무 광범위하게 설정되었는지 확인하고 deny를 할 수도 있다.
Logging
진단 설정을 통해 아래와 같이 logging도 가능하다.
logging 될 때, 추가로 입력한 comments 들도 같이 로깅이 되니, Settings 쪽에서 요청이나 승인시 comment를 강제한다면 자세한 logging이 가능하다.
권한 부여와 항상 같이 따라다니는 부분이, 요청 및 승인에 대한 자료가 필요한데 Settings 에서 필수 필드로 바꿔서 신청 및 허가를 해버리면 따로 email로 상황설명 + 요청할 필요 없이 PIM의 기능만으로 웬만한건 핸들링 할 수 있을 것으로 보인다.
이렇게 사용한지 얼마되지 않아, 추가적인 개선점이 있을 수 있지만, 아마도 큰 문제가 없다면 현 상태로 요청 승인 관련 요구사항들은 compliance 관점에서는 충족이 되지 않을까 싶다.
마치며
아직 도입하여 사용한지는 몇 주 되지 않았지만, 기존의 email로 주고받던 권한 요청 부분을 많이 해소할 수 있어 매우 기대된다. 개선점이 필요하다면 나중에 회고를 통해 다시 한번 기록을 해야겠다.
