Single Sign On: 물어봐야 할 질문

할아버지는 늘 “새로운 건 절대 해보지 마. 누가 먼저 죽는지 보고 해”라고 하셨습니다. 최근 저는 여러 Single Sign On 프로젝트를 실제 성과로 만들기 위해 참여하게 되었고, 그분의 말은 계속해서 제 머릿속 맨 뒤에 맴돌고 있었습니다. 한편에서는 “모든 것에 접근하는 데 사용자 이름과 비밀번호 딱 하나만 두는 건 나쁜 생각이야”라고 말합니다. 해커 공격이 발생하면 침입자가 그들의 모든 것을 손에 넣게 되고, 모든 것에 접근할 수 있게 됩니다. 하지만 다른 한편에서는 그것을 보고 이렇게 말합니다. “사용자들은 이걸 정말 좋아할 거야.” 결국 하라는 대로 해도 바보 같고, 안 해도 바보 같은 전형적인 상황입니다. 그렇다면 어떻게 해야 할까요?

Single Sign On이란 무엇인가요?

처음 Single Sign On(SSO)을 보안 관점에서 바라보는 사람 입장에서는, 하지만 그 세부 작동 원리를 잘 모른다면 SSO는 엔터프라이즈 수준의 자충수처럼 보일 수 있습니다. ‘Single Sign-On’이라는 이름 자체만으로도 모든 것에 대해 한 가지 자격 증명 세트를 사용하는 장면이 떠오르지만, 결론적으로 SSO는 사용자들의 업무를 더 편하게 해 주면서도 보안은 절대 타협하지 않도록 설계되어 있습니다. 여러분이 하는 일은 SAML(Security Assertion Markup Language)이라는 어떤 것을 활용하는 것입니다. 이는 XML 기반의 오픈 소스 데이터 형식으로, 서로 다른 애플리케이션이나 당사자 간에 인증 및 인가 데이터를 교환할 수 있게 해 줍니다. 또한 사용자의 AD 또는 LDAP 정보를 활용함으로써, 말하자면 그 사이에 또 한 겹의 보호막을 더해 실제로 상황을 조금 더 단단하게 만듭니다.

그래서 우리는 그것이 AD에서 이미 부여된 권한에 어떤 영향을 미치는지를 연결함으로써 보안을 강화했습니다. 대부분의 경우, 애플리케이션과 연결된 별도의 사용자 이름/비밀번호가 있다면 그것을 한 번만 입력하면 되고, SSO 앱이 우리에게 접근 권한을 제공합니다. 조금 무섭게 들릴 수도 있지만, 일반적인 AD 잠금(락아웃)은 그대로 작동한다는 점을 기억하세요. 또한 계정이 손상되었을 때의 추가 이점도 있습니다. 대부분의 SSO 소프트웨어에는 정말 강력한 보고(리포팅) 기능이 포함되어 있어, 손상된 계정과 접근된 데이터를 감지할 수 있습니다.

Single Sign On을 도입하기 전에 확인할 질문

여기서는 제가 ‘악마의 대변인’을 맡아 보겠습니다. 모두가 마음속에 품고 있을 질문을 해볼게요. 도대체 이게 실제로 얼마나 안전할까요?

음, 악마처럼(라고 해도) 여러분을 답으로 이끌면서 말해 보자면, 그 내용은 앞으로 몇 주 안에 살펴보게 될 겁니다. 지금은 일단 조직에서 Single Sign On을 도입하고 싶다고 가정해 볼게요. 조직에서 SSO를 원한다면, 다음 몇 가지를 생각해 보셔야 합니다.

가장 먼저 확인해야 할 것은, 우리가 새로 도입하는 것인지 아니면 기존을 업그레이드하는 것인지입니다. 대개는 기존을 대체하는 새로운 SSO 제품인 경우가 많습니다. 그렇다면 바로 교육과 커뮤니케이션부터 고민을 시작해야 합니다. 커뮤니케이션은 사용자가 무엇이 진행되고 있는지 알 수 있도록 하는 것이고, 교육(온라인 동영상만 제공하더라도)은 새 제품을 사용하는 방법을 안내하기 위한 것입니다.

우리는 그걸로 무엇을 하려는 걸까요? 접근을 중앙 집중화하려는 것일까요? 권한 부여를 개선함으로써 보안을 강화하려는 것일까요? 아니면 그저 단순한 감사(오디팅)만을 하려는 것일 수도 있습니다. 어쩌면 이 세 가지를 모두 달성하려는 것일지도 모릅니다. 결론적으로, 모든 작업이 끝났을 때 무엇을 기대해야 하는지 알고 있다면 성공적인 프로젝트를 진행하는 데 분명 도움이 됩니다.

초기에 어떤 애플리케이션에 대한 접근을 제공할지 결정하는 것은 매우 중요합니다. 대부분의 애플리케이션은 SSO와 잘 연동되지만, 그렇지 않은 애플리케이션도 있습니다. 이른바 “그렇지 않은” 것들은 여러분의 업무를 정말 어렵게 만들 수 있고, 제3자까지 관여하거나, 작동시키기 위해 약간의 창의性이 아니라 꽤 많은 노력이 필요할 수도 있습니다. 그러니 그런 점을 예상해 두세요.

누가 그걸 담당할까요? 시스템에 대한 책임을 누군가가 져야 하며, 이를 처리하기 위해 회사 내 서로 다른 수준의 여러 사람이 관여할 수도 있습니다. 예를 들어, 최근 SSO 프로젝트에서는 제가 서버에 설정을 구축하고, 프로젝트 관리를 돕고, 초기 애플리케이션과 사용자 배포(시딩)를 완료하는 일을 담당했습니다. 하지만 초기부터, 앞으로는 신규 사용자를 Tier 1 담당자들이 추가하게 될 것이라고 결정되었습니다. 그래서 우리는 그들을 확보하고, 최소한 그 시점까지는 교육을 제공해야 했습니다. 반면 애플리케이션 관리와 서버의 유지 관리 및 운영(향후 업그레이드와 DR은 말할 것도 없고)은 제 손에 확실히 맡겨졌습니다.

우리가 가장 주의 깊게 살펴야 할, 아마도 가장 중요한 한 가지는、회사가 성장하고 변화해 나갈 때 우리가 구매하는 SSO도 계속해서 확장되고 발전을 거듭하는지 여부입니다.

그리고 60년대에 예전에 그랬듯이, 다이얼은 건드리지 마세요.