카톡만 있으면 다른 서비스 로그인이 가능한 이유
인증을 통합하는 SSO, 데이터 통신을 보안하는 SSL
서비스를 만들고 유지하는 데에 근.본.들이 있겠지만 근본 of 근본은 "인증"이라고 생각한다.
서비스의 사용자가 단 한명이라도 생기는 순간 인증은 없을래야 없을 수 없는 기능이 된다.
그치만... 쪼렙기획자인 나는 모르는 단어들이 여기저기 난무하는 인증이 제일 어렵고,
누가봐도 차가워보이는 교수님께 인사하는 게 떨리는 것처럼
어려운 인증님께 다가가기가 참 무섭다.
교수님, F만 주지 마세요...삐까...하지만! 교수님도 겉만 차가우실 뿐, 사실은 따뜻하고 학생을 누구보다 진심으로 생각해주시는 분일 수 있다.
그러니 우리도 교수님, 아 아니 인증에게 좀더 가까이 가보자!
그나마 사용자에게 가장 친숙한 인증은 뭘까?
나에게는 서비스를 열고, 아이디랑 비밀번호를 쳐서 내가 회원인지 아닌지 확인하고,
휴면 상태는 아닌지 확인하는 회원 인증이 눈으로 확인하기도 쉽고, 가장 많이 접했다.
강남언니 어플를 누르면 첫 화면에 이렇게 로그인을 하는 화면이 뜬다.
강남언니의 로그인 화면옛날에는 무조건 서비스마다 회원가입을 해야했던 거 같은데 (혹시...나...Latte...?)
요즘에는 많은 서비스에서 카카오톡 로그인, 페이스북 로그인 같은 SNS 로그인을 많이 적용해두어서
우리는 다른 서비스의 아이디로도 쉽게 또 다른 서비스를 이용할 수 있다.
그런데.. 이 SNS 로그인은 어떻게 구현되는 걸까?
아이디와 비밀번호가 없어도 어떻게 다른 서비스의 회원 상태를 가져와서 믿을만 한지 파악하는 걸까?
이를 가능하게 한 SSO부터 알아보자.
SSO (Single Sign-On)
#한곳에서만인증되면OK#통합인증시스템
대학생 때만 생각해봐도 학교 사이트, 학점확인 사이트, 기숙사신청 사이트, 수강신청 사이트, 교내 wifi 연결 등등 사용해야하는 사이트가 참 많다.
나의 학번과 비밀번호를 입력하면 사이트는 내가 안전한 사용자인지 인증하고,
재학생인지 휴학중인지 다 판단하고 그에 맞게 날 로그인시킨다.
그럼...이 각각의 사이트가 모두 각자 인증 기능을 가지고 있는 걸까?
만일 그렇다면 각각의 사이트를 개발하기도, 관리하기도 너무 복잡할 것이다. (관리비용도 어마무시ㅠㅠ)
학교나 기업에서 소유하는 사이트들이 많아지면서 이들을 수월하게 관리하기 위한 방법으로 주로 사용하는 것이 바로 싱글사인온(Single Sign-On), 즉 SSO다.
학교, 기업 같은 곳에서 주로 사용되지만
위에서 말한 것처럼 SNS 로그인같이 일반 서비스들에서도 쉽게 보인다.
SSO의 정의
SSO는 하나의 로그인 인증 정보만 있으면 다른 여러 애플리케이션에 접근할 수 있도록
중앙화된 세션 및 사용자 인증 서비스이다.
관리자는 하나의 보안 토큰 (사용자 이름/암호 쌍)으로 여러 시스템과 플랫폼에 대한 사용자 접근을 활성화, 비활성화 할 수 있어 보안 통제 측면에서 굉장히 유용하다.
예를 들어 한 학생이 휴학을 신청한 경우,
그 학생이 기숙사를 신청하거나, 강의를 신청하거나 하는 여러 사이트의 권한을 한꺼번에 회수할 수 있다.
SSO의 장점
관리자는 여러 시스템의 인증 기능을 한 곳에서 통합하여 할 수 있기 때문에, IT 모니터링 및 관리 측면에서 유용하다
학교, 기업 내 다양한 정보 시스템의 구축에 따른 복잡성을 감소시킨다
생체 인식 등 다양한 인증 기술을 활성화할 수 있다
중앙 관리를 통해 업무 단순화 및 표준화를 실현할 수 있다
중앙 집중적인 사용자 관리를 통한 보안 기능을 관리할 수 있다.
ID 공급 업체에서 인증 책임을 지기 때문에, 서비스 공급 업체에서도 책임 관리가 수월하다.
비밀번호 분실이나 취약한 비밀번호의 위험도 낮춰준다.
SSO의 작동 원리
사용자가 웹사이트에 접근을 시도한다.
웹사이트는 사용자를 인증하기 위한 요청으로 이메일 주소와 같은 사용자에 관한 몇 가지 정보가 포함된 토큰을 ID 공급업체(SSO 시스템)에 보낸다.
ID 공급업체는 먼저 사용자가 이미 인증됐는지 여부를 확인한다. 이미 인증이 되었다면 웹사이트에 대한 접근 권한을 부여하고 건너뛴다.
아직 로그인을 하지 않은 경우에는 사용자에게 ID 공급업체가 요청하는 인증 정보를 입력해 로그인하라는 메시지가 표시된다.
입력된 인증 정보가 유효하면 ID 공급업체는 웹사이트에 토큰을 돌려보내 사용자가 인증됐음을 알린다.
웹사이트에 돌려보내는 토큰에는 사용자의 비밀번호나 생체 데이터와 같은 인증 데이터가 포함되어 있지 않기 때문에, 스니퍼(Sniffer)가 토큰을 가로채거나 웹사이트 시스템이 공격받아도 사용자의 ID, 비밀번호는 안전한다.
SSO의 유형에도 여러가지가 있다는데, 거기까지 가면 나의 작은 뇌가 감당할 수 없을 것 같아
여기에서 멈추고 다른 개념을 공부해보았다.
SSL (Secure Sockets Layer)
#http에서https가되기까지#사이트보안
SSL의 정의
지금 보고 있는 사이트의 주소창을 클릭하면, 아마 대부분의 URI가 'Https'로 시작할 것이다.
예전에는 http로 시작하는 사이트가 많았지만, 요즘 사이트는 대부분 https로 시작한다.
https로 시작하는 건 클라이언트와 서버가 안전하게 암호화 통신을 하고 있다는 것을 의미하는 건데,
SSL이라는 보안 프로토콜에 HTTP 프로토콜을 얹어 보안된 HTTP 통신을 하는 구조이다.
즉, SSL 암호화 통신이란 SSL(Secure Socket Layer) 또는 TLS(Transport Layer Security)라는 보안 프로토콜을 통해 더 보안이 향상된 통신을 하는 것을 의미한다.
SSL과 TLS의 차이
SSL에 대해 찾다보면 TLS라는 단어를 많이 접했는데, 이 둘은 같은 뜻으로 말하며
SSL 3.0을 업그레이드한 게 TLS 1.0으로, TLS는 SSL의 업그레이드 버전으로 이해하면 쉽다.
하지만 TLS라는 이름보다는 SSL이라는 이름으로 더 많이 사용되고 있다.
SSL 프로토콜의 통신
1. 핸드셰이크 (handshake)
데이터를 주고 받기 위해 어떤 방법을 사용해야하는지 서로의 상태를 파악한다.
(1) Client hello
브라우저 검색창에 도메인을 입력하는 것처럼, 클라이언트에 서버에게 먼저 문안인사를 드린다.
이따 클라이언트는 자신의 브라우저가 지원할 수 있는 암호화 방식(Cipher Suite)을 먼저 제시한다. 그리고 랜덤 데이터를 생성하여 추가로 전송한다.
(2) Server hello
이제 서버가 클라이언트에 답을 한다. 클라이언트가 제시한 암호화 방식 중 하나를 골라서 알려주고, 자신의 인증서를 전달한다. 이 인증서에는 서버의 공개키가 포함되어 있다.
클라이언트가 그랬던 것처럼 서버도 랜덤 데이터를 함께 전달한다.
(3) Client key exchange
클라이언트는 미리 주고받은 자신과 서버의 랜덤 데이터를 참고하여 서버와 암호화 통신을 할 때 사용할 키를 생성한 후 서버에서 전달한다. 이때 키는 서버로부터 받은 공개키로 암호화되어 보내진다.
(4) Finished
핸드셰이크 과정이 정상적으로 마무리되면, 클라이언트와 서버 모두 "finished" 메시지를 보낸다. 그 후부턴 클라이언트가 생성한 키를 이용하여 암호화된 데이터를 주고받는다.
2. 데이터 전송
서로 간 협상이 완료되면 SSL 세션이 생성되고, 클라이언트와 서버는 원하는 데이터를 주고 받는다.
3. 종료
데이터 전송의 끝을 서로에게 알리며 세션을 종료한다.
SSL 장점
전달되는 내용이 다른 사람에게 노출되는 것을 막을 수 있다.
클라이언트가 접속하려는 서버가 신뢰할 수 있는 서버인지 알 수 있다.
전달되는 내용이 악의적으로 변경되는 것을 막을 수 있다.
서버가 신뢰할 수 있다는 인증서를 클라이언트에 줘야하고, (신뢰할 만한 서버)
클라와 서버 간 데이터가 암호화되어 전달되기 때문에 보안이 향상된다.
인증에 참 많은 개념이 있지만 우선 SSO와 SSL로 시작해보았다.
겁을 잔뜩 먹은 채 시작했지만, 그래도 개념 정도는 이해한 듯 하다.
인증은 서비스 관리에 필수적인 기능인 만큼,
개념이 나올 때마다 너무 쫄지 말고 차근차근 공부해봐야지!
오늘도 글 읽어주셔서 감사합니다 :-)
https://www.itworld.co.kr/howto/193849
https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=wnrjsxo&logNo=221731488194
https://pplus.co.kr/news/?mod=document&uid=339
https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=skinfosec2000&logNo=222135874222
https://goodgid.github.io/TLS-SSL/
