[ Architecture, Technology ,Web ] SSO(Single Sign On) 그리고 SAML에 대해

이미지
이번 프로젝트 내부에서 어쩌다보니  유저 인증 관련 업무를 담당하게 되었고, 해야하는 업무는 내부에 사용했던 적이 없던  새로운 개발 플랫폼에서  SSO의 프로토콜 중  SAML을 이용해 앱의 인증을 구현해야만 했다. SSO를 생각해본적 조차 없는 상황에 이를 새로운 개발 플랫폼에 도입해야 했기 때문에 많은 시행착오를 겪었으나 구현에 성공하였으며 덕분에 SSO에 대한 전반적인 지식을 쌓을 수 있었다. 이번에는 그러한 과정에서 나온 지식들과 경험을  공유하고자 한다. SSO에 대한 정의 먼저 사전적 정의 부터 살펴보자. 다만, 기술적인 용어다보니 자주 사용하는 옥스포드 사전에 정의를 찾을 수 없기 때문에  검색으로 찾을 수 있는 정의를 몇 가지 살펴보고 교차 검증을 해보자. 첫 번째 정의를 살펴보자. Single sign-on (SSO) is an identification method that enables users to log in to multiple applications and websites with one set of credentials.  SSO는 웹사이트에서 한 번의 인증(one set of credentials)으로 복수의 어플리케이션에 로그인 할 수 있는 인증(identification) 방법(method) 이다. 두 번째는 위키피디아의 정의이다. Single sign-on (SSO) is an authentication scheme that allows a user to log in with a single ID to any of several related, yet independent, software systems. SSO는 독립적이지만 연관되어있는 몇몇 소프트웨어에 대해 하나의 ID로 로그인을 할 수 있도록 하는 인증 구조(scheme) 세부 설명에 조금 차이가 있어 보이지만 전체적인 틀은 매우 비슷해 보인다.  몇 가지 포인트가 되는 단어를 추출해 이를 연결해보자면 아래와 같은 의미를 산출 할 수 있다. 독립적이지만 연관되어 있

[ Essay - Technology, IT, 전지적 개발자 시점 ] 크롬과 같은 브라우저의 비밀번호 저장 기능은 정말 안전 한가?


최근 들어서 나는 이전에 
사용하지 않았던 기능을 많이 사용하기 시작했다.

바로 브라우저의 비밀번호 저장 기능이다.

과거에 사용하지 않았고, 
지금에 와서 사용하는 이유는 간단하다.

수 많은 사이트에 계정을 만들어야 했고,
지금에 와서는 관리하기가 너무 힘들기 때문이다.

과거에는 비교적 계정이 관리하기 쉬웠지만,
이곳 저곳에서 계정을 만들기를 요구했기 때문에
자주 사용하는 곳은 상관없지만,

이따금 사용해야 할 때 
계속적으로 아이디와 비밀번호를 잊어버리고
다시 찾아야만 하는 번거로움이 지속 되었다. 

따라서 어느 순간 브라우저 비밀번호 저장 기능을 
사용하게 되었다.

하지만 문득 브라우저에서 제공하는 
이 기능들이 정말로 안전한가에 대한 의문이 들었다.

이번에는 이 브라우저의 비밀번호 저장 기능에 대해 이야기를 나눠보자.

웹 시대의 새로운 딜레마


현재(2020년)에 들어서 
이제 인터넷이라는 것은 세대와 관계 없이 사용하게 되었다.

비교적 과거에 인터넷은 컴퓨터로 이용해야 했기 때문에 
젊은 세대가 이용하는 도구 였지만



애플의 아이폰이라는 스마트폰이 등장하게 되어
어린 아이들은 말할 것도 없고
젊은 세대, 노인 세대 할 것 없이 
각자 소형 컴퓨터를 들고 다니게 되면서 
인터넷은 이제 우리 모두의 도구가 되어 버렸다.

이제는 그 누구도 인터넷의 유용성에 대한 의구심을 품지 않는다.

그렇게 되자 
수 많은 기업들이 인터넷에 뛰어들었고,
자사 시스템을 IT화하는 기업이 대다수다.

사실상 IT와 접목시키지 않는 기업들은
시장에서 점점 뒤떨어지기 시작했다.

오프라인을 중점으로 움직였던 
도 소매 시장도 사실상  
인터넷의 영역에 안에 강력하게 종속 되어버리면서

이제 인터넷은 우리의 생활 마저 종속해버렸다.

이렇게 되자 현대인들은 
한 가지 새로운 딜레마에 빠지게 된다.

수 많은 계정을 어떻게 해야 하는 문제이다.

여기에는 현재 아래와 같이 
여러가지 솔루션이 제시될 수 있다.

① 아이디와 비밀번호를 모두 통일 한다.

② 아이디와 비밀번호를 모두 외운다.

③ 브라우저의 저장 기능을 사용 한다.

④ 아이디와 비밀번호를 모두 메모해 둔다.

하나씩 차례대로 이야기를 나눠보자.

① 아이디와 비밀번호를 모두 통일 한다.


계정을 만들 때마다 아이디와 비밀번호를 통일하게 되면 
이러한 딜레마로 부터 벗어날 수 있다.

하지만 누가 봐도 썩 좋은 방법으로 보이지는 않는다.

왜냐하면, 하나의 아이디와 비밀번호가 노출되면 
모든 계정이 위험에 노출되기 때문이다. 

너무나도 간편하지만, 그 만큼 리스크가 너무 크다.

② 아이디와 비밀번호를 모두 외운다.


여러 솔루션 중에 
이 방법이 가장 보안의 문제가 없어 보인다.

가능하다면 말이다.

하지만, 인터넷에 시대에 살고 있으면서
계속해서 늘어나는 자신의 계정의 
모든 아이디와 비밀번호를 외울 수 있는 사람은 매우 드물 것이다.

왜냐하면 그런 곳에 한정된 시간을 쓰기에는 
너무나도 시간이 아깝기 때문이다.

가장 보안의 문제가 없어보이지만, 
효율이 너무 떨어진다.

③ 아이디와 비밀번호를 모두 메모해 둔다.


이 방법도 말만 놓고 따지면 꽤 나 좋아 보인다.

하지만, 어느 곳에 메모를 해둘 것인지를 고려해봐야 하고 
이 메모를 안전하게 보관할 효율적인 방법도 또한 제시해야만 한다.

스마트폰에 보관한다고 하더라도
스마트폰 보안이 100% 안전하다고 할 수 없으며,
열었을 경우 모든 아이디와 비밀번호가 노출되기 때문에

문제를 해결한 듯 하게 보이지만, 새로운 문제가 나타날 뿐이다. 

④ 브라우저의 저장 기능을 사용 한다.


여러가지를 고려했을 때, 적어도 나는 이 방법이 
여러가지 의미에서 가장 효율적으로 보였다.

다만, 우리는 아래와 같은 의문이 들 수 있다.

각 회사에서 제공해주는 브라우저의 계정 저장 기능의 
아이디와 비밀번호, 특히 비밀번호가 
과연 정말 안전하게 보관 되는가?

하는 의문이다.

이제 본격적인 이야기에 들어가보자.

컴퓨터 암호 시스템은 어떻게 이루어져 있는가?


비밀번호 저장 기능이 정말로 
안전한지에 대한 이야기를 하기 전에

먼저 현재의 컴퓨터 암호 시스템이 
어떻게 이루어져 있는지에 대한 이해가 필요하다.

결론부터 말하면 
현재 컴퓨터 암호 시스템에서 100% 안전하다고 할 수 없다.

왜냐하면 원문(Plain Text)을 수학적으로 암호화 하지만
결국 시간이 지나면 원문을 알아낼 수 있기 때문이다.

예컨데, 
과거 부터 지금 까지 사용되고 있는 암호 시스템 중에서
AES(Advanced Encryption Standard), 
한국어로는 고급 암호화 표준이라는 시스템이 있는데

이 중 AES-128의 무차별 공격(brute force)을 시도 할 시에 2^88 bit 만큼의 
bit 데이터가 필요하고, 약 38조 테라 바이트가 필요하다.[1]

좀 더 쉽게 말하면 AES의 128bit의 암호키를 가지는 
암호 시스템을 사용하면,
무작위로 하나하나씩 모든 암호를 대입해보는 

가장 원시적인 무차별 공격(brute force)의 경우 
2^88 bit 만큼의 
예상되는 원문(Plain Text)를 만들어내야 하며,
이 중 단 하나만이 원문(Plain Text)이라는 것 이다.

이는 AES 뿐만 아니라 다른 암호 시스템들도
모두 동일하다. 

따라서 현대 암호 시스템에서 
100% 보안이 완벽하다고 하기는 불가능하다.

결국 시간이 지나면,
혹은 컴퓨터의 성능이 뛰어나면 그에 비례해서 
시간이 줄어들기 때문이다.



그렇기 때문에 양자 컴퓨터가 나오면
현대의 암호 시스템이 모두 쓸모 없어진다는 이야기가 나오는 것이다.

공격자가 원문(Plain Text)를 얻어내지 못하게
시간만 질질 끌어내는 것이 
현실의 암호 시스템의 장점이자 한계이다.

브라우저의 비밀번호 저장 기능은 어떠한가?


위의 이야기로 부터 
우리는 현대 암호 시스템의 한계를 봤고 
결국 100% 안전한 암호 시스템은 없다는 걸 알아내었다.

하지만, 그렇다고 하더라도 
현대 암호 시스템이 공격자의 발목만 잡아 
질질 끄는 것이라고 하더라도 

일반적인 현대 컴퓨터 성능으로는 
알아내기 어렵기 때문에 99%정도는 안전하다고 볼 수는 있을 것 이다.
(그럼에도 의심을 떨쳐내기는 힘들겠지만 말이다)

브라우저에서 정보를 받아올 때 
주로 쿠키세션 형식을 통해 받아오게 되는데,
이 둘에 대한 이야기는 아래의 링크에서 참고하기를 바란다.


그렇다면 다시 본론으로 돌아와 
이런 브라우저 중 구글의 Chrome은 어떠할까?

나는 이에 대해 2019.03.25에 개설된
Are Chrome saved passwords really safe?라는 이름의 쓰레드를 찾을 수 있었다.[2]

이 글의 원문은 아래와 같다.



쓰레드 작성자는 특별한 권한 없이 제3자가 
내 계정 안전에 엑세스 할 수 있는 이유에 대해 궁금해 하고 있다.

이에 대한 대답으로 2가지 URL을 누군가가 코멘트로 달았는데

먼저 첫 번째[3]는 

운영 체제 별 분류가 되어있는 것을 보면
저장 시스템의 알고리즘이 운영 체제 별로 다른 것으로 보이며

Windows의 경우만 살펴보면 아래와 같다.

Windows에서 Chrome은 DPAPI(Data Protection API)를 사용하여 
비밀 번호를 사용자 계정에 묶고(bind),
동일한 로그인된 사용자로 실행되는 프로세스만이 엑세스 할 수 있는 
키로 암호화된 것을 디스크에 저장 합니다.

설명보다 직접 실행해보는 것이 빠를 것 이다.

먼저 크롬의 암호 관리 시스템에 들어가보자.


들어가보면 위와 같은 화면이 나올 것이고,
등록되어 있는 웹 사이트와 아이디, 
그리고 패스워드가 마스킹 되어 있는 것을 확인할 수 있다.

여기서 빨간색 박스의 아이콘을 클릭하면 


위와 같이 Windows 로그인 계정의 비밀번호를 요구하며,
올바른 비밀번호를 작성할 경우 
해당 웹사이트의 마스킹되어 있는 패스워드가 보여지게 된다.

두 번째[4]의 경우,


Why aren‘t physically-local attacks in Chrome’s threat model?이라는 
제목의 한국어로 직역하면
물리적 로컬 공격은 크롬에서 위협 모델이 아닌 이유는 무엇인가?
라는 타이틀 인데,

해당 내용은 대략적으로 아래와 같다.

Chorme에서는 기기에 로그인한 악의적 사용자 또는 
귀하의 운영체제 권한으로 소프트웨어를 실행할 수 있는 
악의적 사용자를 방어할 방법이 없기 때문에 위협 모델이 아닙니다.

라고 한다.

즉, 기기에 로그인한 사람이 정말 본인인지 아닌지는 
Chrome이라는 소프트웨어가 판별할 수 없기 때문에
Chrome의 위협 모델로 볼 수 없다는 것이다.

이 경우는 매우 자명해 보인다.

왜냐하면 기본적으로 지금의 보안 시스템으로서는 
올바른 패스워드를 입력하는 사람이 
악의적 공격자 인지 그렇지 않은지에 대한 판단을 할 수 없기 때문이다.

물론 현재에 이런 문제에 대한 솔루션은 이미 제시되어 있다.

패스워드가 아닌 얼굴 인식 시스템이나, 
지문 인식 시스템을 활용하면 가능하다.

하지만, 아직까지는 패스워드를 활용하는 
사람이 많기 때문에 물리적 로컬 공격에는 취약할 수 밖에 없을 것이다.

이 2가지 게시물로서 알 수 있는 사실은 아래와 같다.

Chrome 비밀번호 시스템에서는
Windows의 경우 사용자 계정을 신뢰할 수 있는 사용자로 보기 때문에 

윈도우 사용자 계정에 로그인할 수 있다면 
Chrome 비밀번호 시스템에서 비밀번호를 취득할 수 있다.

라는 것 이다.

브라우저의 비밀번호 저장 기능을 좀 더 안전하게 사용할 수 있는 방법은 무엇인가?


위에서 도출한 사실을 기반으로 
유용한 브라우저의 비밀번호 저장 기능을 사용하기 위해 
좀 더 안전하게 사용하기 위한 솔루션을 몇 가지 제시해볼 수 있다.


첫 번째, 윈도우 사용자 계정을 생성 및 관리

두 번째, 해당 비밀번호를 저장하고 있는 구글 계정의 보안 강화 
 
세 번째, 유로 백신 소프트웨어 사용


이 3가지 방법에 대해 조금 더 자세히 이야기 해보자.

① 윈도우 사용자 계정 생성 및 관리


개인 컴퓨터 보안에서 가장 우선 시 되는 것은 
운영 체제의 계정을 만드는 것 이다.

운영 체제의 계정을 만들지 않고
컴퓨터 보안의 문제를 논하는 것은 넌센스이다.

계정을 만드는 것이 첫 번째이고,
그 다음이 백신 소프트웨어이다.

없다면 먼저 안전한 컴퓨터 사용을 위해 
그리고 인터넷 사용을 위해 계정을 생성하자.

이에 추가적으로 고려해볼법만 한 것은 
윈도우에서 지원해주는 지문 인식과 
지문 인식 USB 모듈을 사용하는 것이다.



위와 같이 대략 20~30 달러 정도면 
USB 모듈을 구입할 수 있다.


② 구글 계정 보안 강화


구글의 계정 보안 강화는 



위의 빨간색 박스의 계정 보안 강화란에 들어가서

계정 보안에 문제가 없는지 확인하고,
등록하지 않았다면 등록하는 것이 좋다.

특히 3가지 빨간색 박스를 관리할 필요가 있는데,

이 중 가장 중요한 것은 
첫 번째 박스와 두 번째 박스이다.

먼저 첫 번째 박스


위와 같이 해당 구글 계정에서 로컬로 판단하는 
기기들이 등록되어 있는데,

만약 공격자가 여기에 자신의 기기를 등록하면
크롬 패스워드 관리 시스템에서
당신의 패스워드를 취득하기 위한 첫 번째 조건을 달성한 것 이다.

따라서 보안 강화를 위해서는
자신이 사용하지 않는 기기들은 모두 삭제하고 
지속적으로 관리가 필요하다.


세 번째 박스


새로운 기기에서 계정에 접속할 때 사용하는 전화번호와
복구하기 위한 이메일 들을 설정할 수 있다.

새로운 기기가 등록되거나 계정의 비밀번호가 변경될 때 
복구 메일로 통지 메일이 전송된다.

실제로 나는 몇 개월전에 누군가가 
내가 사용하지 않는 계정을 복구 계정으로 등록했었는데 

'image.png' 업로드를 하지 못했습니다.

위는 나의 메일로 전송되어진 실제 메일이다.

gg273546@gmail.com이라는 계정이 
내 구글 계정의 복구 계정으로 등록된 것이다.

나는 나의 이메일로 
이를 알려줘서 바로 삭제해버렸다.

아마 내 구글 계정의 보안을 강화하지 않았다면
나의 패스워드를 위의 공격자가 탈취해갔을 것이다.

다음은 당신이 공격 당하지 않을 것이라는 보장은 없다.

③ 유로 백신 소프트웨어 사용


물론 무료 백신 프로그램을 사용하는 것도 상관 없다.

사용하지 않는 것보다는 나을 것이다.

하지만, 나는 주로 카페에서 시간을 보내며
카페 공용 Wi-Fi를 사용하기 때문에 
Wi-Fi 관련 보안을 강화해주는 소프트웨어를 구입해 사용하고 있다.

그렇지 않다고 하더라도 
조심해서 나쁠 것은 없기 때문에 
가급적 유료 백신 소프트웨어를 사용하기를 권장한다.

최근에는 여러 디바이스를 추가할 수 있게 끔 
허용해주는 곳이 많기 때문에 
돈이 아깝다는 생각은 크게 들지 않는다.

나는 1년동안 3개의 디바이스에서 사용할 수 있는 
4만원 정도의 소프트웨어를 사용하고 있다.

결론


앞서 우리는 크롬과 같은 
브라우저의 비밀 번호 저장 시스템에 대해 이야기 해보았고,
이에 대한 솔루션에 대한 이야기도 해보았다.

결론적으로 100% 완벽한 보안이란 존재할 수 없다.

왜냐하면 컴퓨터 암호 시스템 자체가
공격자의 발목을 잡고 길게 늘어지는 형태이기 때문이다.

따라서 시간이 지난다면, 
계산이 빠른 컴퓨터(특히 양자 컴퓨터)라면, 
이런 암호 시스템은 완전히 무너질 것 이다. 

이 경우 어쩌할 방법이 없다.

이는 구글 크롬 브라우저의 패스워드 시스템 뿐만 아니라
다른 보안 시스템에서도 마찬가지이다.

하지만, 위에서 내가 제시한 솔루션으로 
브라우저의 비밀번호 저장기능에 대해서는 
99.9%까지 끌어올릴 수는 있다.

0.01%의 경우는 어쩔 수 없다.

여기에 99.999999%로 끌어 올리고 싶다면
일정 기간이 지나면, 비밀 번호를 변경 한다면 된다.

비밀 번호 자체를 변경해버리면, 
공격자가 하고 있던 기존의 프로세스는 무용지물이 된다.

왜냐하면 기본적으로 공격은 암호화된 텍스트를 가지고 
원문(Plain Text)를 얻어 내는 것이기 때문이다.

하지만, 한 가지 인지하고 있어야 하는 점은
기본적인 사용자 보안 규칙도 준수하지 않는다면 
그 어떤 보안도 무용지물이라는 것 이다.

예컨데 운영 체제의 사용자 계정을 만드는 것이 
그 중 하나이며,
의심되는 파일을 다운 받는 것도 마찬가지이다.

이를 준수하지 않을 경우의 책임은 
사용자가 일부 지는 것 이다.

이를 고려해 컴퓨터를, 
그리고 인터넷을 사용할 필요가 있다.


이 블로그의 인기 게시물

[ Web ] 웹 애플리케이션 아키텍처 (Web Application Architecture)

[ Web ] 서버 사이드(Sever Side) ? 클라이언트 사이드(Client Side)? 1 [서론, 클라이언트 사이드(Client Side)]

[ Web ] 웹 애플리케이션? 웹 사이트?(Web Application? Web Site?)