세일포인트 Status update

안녕하세요. 제 세션에 오신 것을 환영합니다. 제 이름은 윌 해링턴입니다. 저는 SailPoint의 아이덴티티 전략가이며, 오늘은 정부 기관을 대상으로 하는 4부작 웨비나 시리즈의 첫 번째 세션입니다. 이번 웨비나 시리즈를 통해, 일반적인 정부 환경에 아이덴티티 프랙티스를 어떻게 적용할 수 있는지에 대해 말씀드리겠습니다. 그중 하나가 정부 조직 개편, 즉 ‘machinery of government’ 변화이며, 아이덴티티 거버넌스(저는 IGA 시스템이라고 부르겠습니다)가 이러한 정부 조직 운영 체계의 한 부분으로서 큰 효과를 내고 매우 유용할 수 있다는 점을 다룰 예정입니다. 향후 웨비나 녹화본에서는 아이덴티티 거버넌스를 사이버보안과 어떻게 통합할 수 있는지, 또 아이덴티티 거버넌스에서 AI가 어떤 역할을 하며 그 영향이 무엇인지에 대한 세션, 그리고 시리즈의 마지막 녹화본에서는 비즈니스 케이스를 구축하는 방법을 논의할 예정입니다.

정부 조직 개편 변화를 안전하게 관리하는 맥락에서, 앞으로는 MOG라고 부르겠습니다. ‘Machinery of government’라는 표현이 발음하기도 어렵고, 좀 피곤해지기도 해서요. 그래서 MOG와 IGA로 줄여서 말씀드리겠습니다. 제가 MOG라고 하면, ‘machinery of government’ 변화, 즉 정부 조직 개편을 말씀드리는 것으로 이해하시면 됩니다. 오늘 발표의 일환으로, ‘machinery of government’ 변화가 무엇인지부터 다루겠습니다. 정부 대상 웨비나이니, 오늘 참석하신 분들은 ‘machinery of government’ 변화가 무엇인지 정확히 알고 계시리라 생각합니다. 민간 부문에서 오신 분들께는, ‘machinery of government’ 변화는 단순히 조직개편(reorg)과 비슷하다고 보시면 됩니다.

조직 내에서 조직개편을 자주 겪고 계시다면 같은 논리를 적용할 수 있을 것이고, 오늘 말씀드리는 내용은 정부와 민간 모두에서 충분히 서로 적용 가능한 내용입니다. 오늘은 정부 환경에서 ‘machinery of government’라는 맥락 속 조직개편을 다룰 예정이며, 그 과정에서 공공 부문에 많은 초점을 맞추게 될 것입니다. 목차 두 번째는 MOG를 관리할 때의 과제입니다. 그게 무엇인지, MOG가 무엇인지 살펴보겠습니다. MOG 관리의 과제입니다. MOG 과정에서는 많은 데이터가 이관되고 변경되는데, 그 세부 내용과 현재의 실무 관행이 무엇인지까지 다루겠습니다.

저는 지금까지 멜버른, 애들레이드, 시드니에서 열린 여러 Public Sector Network 행사에서 발표할 수 있는 기회를 가졌고, 브리즈번에서도 발표할 예정입니다. 저는 많은 공공부문 직원분들과 이야기할 기회가 있었고, 정부조직(MOG) 변경을 어떤 방식으로 진행하는지에 대해 질문드렸는데, 그 과정에 대한 몇 가지 세부 사항을 공유해 주셨습니다. 그래서 이는 그 공유 내용을 조금 취합한 것이고, 제가 보기에 가장 흔하게 나타난 내용을 정리한 것입니다. 그리고 이제 본격적인 부분으로 들어가서, 아이덴티티 거버넌스(IGA) 시스템이 MOG 변경을 원활히 하는 데 어떻게 활용될 수 있는지 말씀드리겠습니다. 무엇을 자동화할 수 있을까요? 마지막으로 비즈니스 케이스를 어떻게 구축할지로 마무리하겠습니다. MOG의 관점에서 비즈니스 케이스를 어떻게 구축할까요? MOG는 정부 운영에서 매우 큰 부분을 차지합니다.

이런 일은 항상 일어납니다. 그렇다면 우리는 그 정보와 그 정도로 큰 변화의 규모, 그리고 프로세스의 비효율성을 활용해 “좋습니다. 아이덴티티 거버넌스 시스템이 없다면, 데이터를 어떻게 구성해서 향후 아이덴티티 거버넌스 시스템 도입을 위한 비즈니스 케이스를 만드는 데 활용할 수 있을까?”라고 말할 수 있는 방법이 분명 있을 것입니다. 저는 MOG가 그 대화를 시작하기에 정말 좋은 출발점이라고 생각합니다. 발표 한 번으로 조직도가 전체적으로 다시 그려지기도 합니다. 제가 앞서 말씀드린 것처럼, MOG는 조직개편입니다. 이는 선거 결과가 나오거나, 정책 변화와 소관(포트폴리오) 변경을 수반하는 새로운 부처가 생기는 경우에 해당합니다.

이는 지난주 빅토리아 주정부에서 우리가 실제로 본 사례인데, 새 주총리가 취임하면서 새로운 포트폴리오를 맡은 장관들로 구성된 새로운 내각이 꾸려졌고, 그 포트폴리오들이 통합되거나 분리되거나 다른 장관에게로 이관됐습니다. 이것이야말로 정부조직(MOG)의 핵심입니다. 결국 그 장관들이 부처와 인력을 재편해 더 효율적이고 더 효과적으로 만들고, 장관의 정책 목표를 달성하는 데 부합하도록 조직을 정비함으로써, 부처와의 소통이 더 쉬워지고 정부 운영 과정에서 변화를 실행하기가 수월해지기 때문입니다.

그 결과 변화가 매우 많이 발생합니다. 많은 직원분들이 직함이 바뀌고, 도메인 또는 이메일 도메인 접미사가 바뀌고, HR 속성이 바뀌고, 보고 라인의 상급 관리자도 바뀔 수 있습니다. 사람들이 조직 내에서 이동하는 방식은 매우 다양하며, 이는 공공부문뿐 아니라 민간 부문에서도 상당히 자주 볼 수 있습니다. 저는 금융서비스기관(FSI)과 가까이 협업하는 경우가 많은데, 매년 여기저기에서 크고 작은 조직개편이 있고, 관리자가 바뀌며, 직원들은 자신의 직무에 다시 지원해야 하는 일이 생기곤 합니다. 공공부문도 사실상 똑같지만, 변화량이 매우 많다는 점이 다릅니다. 이런 일은 꽤 자주 일어납니다. 정부가 바뀌면, 모든 것이 재편되는 경향이 있습니다.

이것은 직원에게만 해당하는 것이 아니라, 부처에서 일하는 계약직 인력도 마찬가지로 시스템과 접근 권한을 올바른 부서로 옮겨야 합니다. 사실 이런 비인간 엔터티들에 대해서도 같은 질문을 던져야 합니다. 요즘은 에이전트와 머신 계정에 대해서도 많이 이야기하고 있습니다. 서드파티에 대해서도 이야기해 왔는데, 그렇다면 그 에이전트들의 소유권은 어떻게 되는 걸까요? 질문이 정말 많습니다. 그 접근 권한을 가진 직원들과 계약직 인력의 모든 접근 권한은 어떻게 되는 걸까요? 이것이 오늘 대화의 핵심인데요, 실례합니다만, 때로는 그 접근 권한이 그대로 유지되기도 합니다. 때로는 갖고 있으면 안 되는 계정을 사람들이 계속 보유하기도 합니다. 때로는 계정이 활성화된 상태로 남아 있기도 합니다. 때로는 사람들이 그 접근 권한을 계속 쥐고 있고, 또 때로는 그 접근 권한이 위협 벡터의 일부로 악용되기도 합니다.

이런 것들이 바로 MOG 변경 과정에서 우리가 해결하려는 문제들입니다. 다시 말씀드리면, 권한(Entitlements)은 비공개로 분류될 수 있는 기록에 대한 접근을 제공합니다. 한 부처에서 다른 부처로 이동하거나 한 정부에서 다른 정부로 바뀌는 사람들은, 동일한 기록에 대한 접근 권한을 계속 유지해야 할까요? 그걸 어떻게 효과적으로 관리하십니까? 특정 시점에 변화가 대량으로 발생하고, 그 변화가 일정한 기한 내에 이루어져야 하기도 한데, 그런 상황에서 그걸 어떻게 처리하십니까? 이 모든 것의 최종 결과는 무엇일까요? 여전히 시민들에게 서비스를 효과적으로 제공할 수 있게 되는 것입니다.

공공 서비스가 기존처럼 효율적인 속도로 계속 운영되도록 보장하는 동시에, 이러한 MOG를 수행하면서도 대국민 SLA를 계속 충족할 수 있도록 하는 것입니다. 일의 진행 순서를 보면, 혹시 모르실까 봐 말씀드리면, MOG 지시가 발표되고 스프레드시트가 작성됩니다. 제가 이런 PSN 행사 참석자들 다수와 나눈 공통된 이야기 중 하나는, 그분들이 MOG를 거의 전적으로 많은 스프레드시트로 처리해 왔다는 점이었습니다. 그 스프레드시트를 가지고 무엇을 하느냐면요?

이름, 역할, 그리고 취합된 접근 권한을 정리한 뒤, 그 스프레드시트 상당수는 서비스 데스크로 바로 제출되어 서비스 데스크 담당자가 변경을 수동으로 적용합니다. "접근 권한 추가 및 회수 지시나 작업이 포함된 30명 명단이 있다"는 식이죠. 그러면 서비스 데스크의 누군가는 여러 애플리케이션과 시스템을 일일이 처리해야 합니다. 예를 들어 액티브 디렉터리(Active Directory)는 수백 개 애플리케이션을 대표할 수 있고, 또 세일즈포스(Salesforce) 같은 SaaS 애플리케이션에서는 더 직접적인 접근 권한이 있을 수도 있으며, 또는 데이터베이스 관리자로서 데이터베이스를 직접 다루고 있을 수도 있습니다. 서비스 데스크는 이 목록들을 반복적으로 검토하면서 필요에 따라 접근 권한을 부여하거나 회수할 수 있어야 합니다. 운영 측면에서 보면 이는 대단히 비효율적입니다. 이런 수작업, 수동적인 노력은 분명히 실수에 노출될 수밖에 없습니다.

제가 한 줄을 놓칠 수도 있고, 제거해야 하는 접근 권한을 빠뜨릴 수도 있습니다. 추가해야 하는 접근 권한을 놓칠 수도 있습니다. 스프레드시트 자체에 오류가 있을 수도 있고요. 그 스프레드시트 중 하나에서 단순한 키 입력 오류만 있어도 특정 사용자의 접근 권한이 깨질 수 있고, 제출된 데이터의 품질 때문에 사용자를 아예 설정하지 못하는 경우도 있을 수 있습니다. 또 PSN 행사에서 만난 몇몇 분들과 얘기해 보니, 스프레드시트를 쓰긴 하지만 파워셸(PowerShell) 스크립트나 각종 스크립트로 스프레드시트 작업을 전부 처리한다고 하셨는데, 이것도 꽤 흔합니다. 그런데 그 과정의 감사 가능성은 어디에 있나요? 그 스프레드시트에 대해 실행되는 코드가 제대로 된 것인지 어떻게 알 수 있을까요? 그 코드에 빠뜨리는 부분이 없는지, 다시 말해 뭔가 누락된 것이 없는지 어떻게 알 수 있을까요?

혹은 그 코드가 접근 권한을 추가하는 데는 정말 능숙하지만, 회수는 하지 못할 수도 있습니다. 그 코드에 대한 가이드라인은 무엇인가요? 누가 그것을 소유하나요? 그 코드를 작성한 사람이 공공 서비스를 떠나서 더 이상 참조할 수 없게 되면 어떻게 하나요? 그걸 어떻게 감사하나요? 이 코드가 괜찮은지, 그리고 이 코드의 재사용성은 어떤지 어떻게 알 수 있을까요? 즉, 스프레드시트라는 세계에서만 처리하다 보면 정말 큰 문제들이 생깁니다. 그래도 괜찮습니다. 저희에게는 좋은 해답이 있습니다. 계정은 수기로 입력합니다. 이게 스프레드시트에서 이어지는 방식이고, 그다음에는 접근 권한을 그대로 복사해 붙입니다. 정부 행사에서도 제가 꽤 자주 들었던 또 다른 얘기는, “그럼 대상 환경, 예를 들어 대상 부서에서 사용자를 어떻게 설정하느냐”는 것이었습니다.

저희가 하는 방식은 비슷한 사람을 찾아보는 겁니다. 비슷한 관리자, 비슷한 부서, 비슷한 코스트 센터, 비슷한 직무 코드 같은 사람을요. 그리고 그 사용자를 그냥 복사해서 붙여넣습니다. 그러니까 예전 메인프레임 환경에서 저희가 ‘모델 ID(Model ID)’라고 부르던 건데요. 누군가를 그대로 복제해서 신규 사용자를 설정하곤 했습니다. 그런데 그 방식은 오류가 꽤 많이 발생합니다. 이제는 모델 ID 시대는 지났고, 그런 방식은 접근 권한을 설정하는 과정에서 권한이 점점 늘어나거나(permissions creep), 개인에게 과도하게 권한을 부여하는(over-entitling) 기회를 만들어낼 수 있습니다. 다섯 번째와 여섯 번째입니다. 또 하나는 기존 접근 권한의 비활성화를 나중으로 미루고, 정리 작업도 미뤄지는 경우입니다. 둘은 같은 얘기인데요. 여기서는 변경 물량이 매우 큰 상황을 다루고 있습니다.