인증·인가·암호화, 각자 맡은 일이 다르다

로그인만 통과하면 끝이라는 착각

인증·인가·암호화, 셋 다 '보호'라는 말로 묶여 있어서 처음엔 한 덩어리처럼 느껴지시죠. 그러다 보니 로그인만 잘 붙여 두면 보안이 끝난 것 같은데, 실제 사고는 그다음 단계에서 자주 생겨요. 이 글에서는 셋이 각각 어떤 질문에 답하는지, 그리고 서로 대신해 줄 수 없는 지점이 어디인지 정리해 드릴게요.

솔직히 말하면, 이 세 단어는 보안 문서에 가장 자주 등장하면서 입문자가 가장 자주 뒤섞는 단어이기도 해요. 셋 다 보호와 관련이 있고 대개 함께 쓰이니까 하나의 큰 덩어리처럼 느껴지는 게 당연해요. 하지만 셋은 서로 다른 질문에 답하는 장치이고, 하나가 다른 하나를 대신해 주지는 않아요.

세 단어를 질문 형태로 바꿔 보면 역할이 선명해져요. 인증은 '너는 누구인가', 인가는 '너는 무엇을 할 수 있는가', 암호화는 '이 내용을 가로채도 읽을 수 있는가'에 답해요. 실제 사고 중 상당수는 셋 중 하나가 아예 없어서가 아니라, 하나가 다른 하나까지 해 줄 거라 믿고 넘어간 자리에서 생겨요.

인증: 주장하는 신원이 맞는지 확인하기

인증은 접근하려는 상대가 주장하는 신원이 실제로 맞는지 확인하는 과정이에요. 아이디와 비밀번호를 넣는 로그인이 가장 익숙한 형태예요. 확인에 쓰이는 재료는 크게 세 가지로 나뉘어요. 아는 것(비밀번호, PIN), 가진 것(스마트폰, 보안 토큰, 인증서), 그리고 자신의 특성(지문, 얼굴)이에요. 성격이 다른 재료를 둘 이상 함께 요구하는 것이 다단계 인증이에요.

재료를 겹쳐 쓰는 이유는 각각의 약점이 다르기 때문이에요. 아는 것은 남에게 알려지는 순간 끝이고, 가진 것은 잃어버릴 수 있고, 특성은 바꿀 수 없다는 점이 장점이자 약점이에요. 서로 다른 성격을 겹치면 하나가 무너져도 나머지가 남아서 훨씬 든든해져요. 다만 인증이 확인해 주는 건 '누구인지'까지예요. 그 사람이 무엇을 해도 되는지는 전혀 알려 주지 않아요.

인가: 확인된 사람에게 무엇을 허용할지 정하기

인가는 확인된 신원에게 어떤 행동을 허용할지 정하는 단계예요. 같은 사내 시스템에 로그인해도 인사 담당자는 급여 자료를 볼 수 있고 다른 부서 직원은 볼 수 없다면, 그 차이를 만드는 게 인가예요. 인증이 건물 정문을 통과하는 일이라면, 인가는 층마다 방마다 다르게 걸린 출입 권한에 해당해요.

여기서 많이들 헷갈리세요. 로그인 화면은 공들여 만들어 두고, 일단 로그인한 사용자라면 무엇이든 요청할 수 있게 열어 두는 경우가 드물지 않아요. 화면에서 메뉴를 감추는 것과 요청을 처리하는 쪽에서 권한을 검사하는 건 완전히 다른 일인데, 앞의 것만 해 두고 인가를 했다고 여기기도 해요. 권한 검사는 실제로 데이터를 꺼내는 자리에서 이뤄져야 의미가 있어요.

암호화: 읽지 못하게 만들되, 막지는 않는다

암호화는 정보를 정해진 열쇠 없이는 의미를 알 수 없는 형태로 바꾸는 기술이에요. 저장된 데이터를 대상으로 하기도 하고, 오가는 통신을 대상으로 하기도 해요. 웹 주소에 https가 붙는 것이 통신 구간 암호화의 익숙한 예예요. 그리고 암호화의 실질적인 핵심은 알고리즘보다 열쇠 관리에 있어요. 열쇠를 데이터 옆에 함께 보관해 두었다면 자물쇠와 열쇠를 같은 문고리에 걸어 둔 것과 다르지 않아요.

암호화가 지켜 주지 못하는 영역을 아는 것도 그만큼 중요해요. 암호화는 정당한 열쇠를 가진 쪽에는 아무런 저항을 하지 않아요. 권한이 잘못 부여된 계정이 정상 경로로 데이터를 조회하면, 그 데이터는 읽을 수 있는 상태로 그대로 전달돼요. 통신이 암호화되어 있어도 사용자가 속아서 직접 정보를 입력해 보내면, 암호화는 그 전송을 안전하게 지켜 줄 뿐 잘못된 상대에게 가는 것까지 막지는 않아요. 하나만 기억하시면 돼요. 암호화는 인가의 대체품이 아니에요.

해시는 암호화가 아니다

해시는 암호화와 나란히 언급되지만 목적이 달라요. 암호화는 나중에 되돌려 읽는 걸 전제로 한 양방향 변환이고, 해시는 원래 값으로 되돌릴 수 없는 단방향 변환이에요. 같은 입력은 언제나 같은 결과를 내고, 입력이 조금만 달라져도 결과는 완전히 달라져요. 이 성질 덕분에 값을 저장하지 않고도 값이 같은지 확인할 수 있어요.

그래서 비밀번호는 암호화가 아니라 해시로 저장하는 것이 원칙입니다. 서비스는 사용자의 비밀번호 원문을 알아야 할 이유가 없고, 입력값의 해시가 저장된 해시와 일치하는지만 확인하면 되니까요. 파일이 전송 도중 변조되지 않았는지 해시값을 비교해 확인하는 것도 같은 성질을 쓰는 거예요. 이쪽은 기밀성이 아니라 무결성 영역의 활용이고요. '비밀번호를 찾아 원문 그대로 알려 드립니다'라는 안내가 있다면, 그 자체가 설계를 다시 볼 신호로 읽혀요.

로그인 이후의 시간: 인증 상태는 세션으로 이어진다

인증은 로그인 순간의 사건이지만, 서비스는 화면을 옮길 때마다 비밀번호를 다시 묻지 않아요. 대신 '확인이 끝났다'는 표식을 발급해 두고, 그 표식이 유효한 동안에는 같은 사람으로 봐요. 이 표식을 세션 또는 토큰이라고 불러요. 결국 로그인 이후에는 비밀번호가 아니라 이 표식이 신원을 대신하는 셈이라, 표식 자체도 지켜야 할 대상이 돼요.

이게 왜 중요하냐면요, 로그아웃과 만료 시간이 의미를 갖는 이유가 여기에 있어요. 로그아웃은 표식을 무효로 만드는 행위이고, 만료는 표식이 영원히 살아 있지 않도록 거는 안전장치예요. 공용 컴퓨터에서 창만 닫고 자리를 떠 본 적, 찔리시는 분 계시죠? 로그아웃 없이 자리를 뜨면, 인증 재료를 아무리 강하게 골랐어도 살아 있는 표식이 그 자리에 남아요. 계좌 이체나 비밀번호 변경처럼 민감한 작업 앞에서 서비스가 비밀번호를 한 번 더 묻는 것도 같은 이유예요. 세션이 유지되고 있다는 것과 지금 화면 앞에 그 사람이 앉아 있다는 건 다른 문제니까요.

이제 이렇게 정리해 두시면 돼요. 어떤 서비스를 보든 '누구인지 확인했나(인증)', '무엇까지 허용했나(인가)', '가로채도 못 읽게 했나(암호화)' 세 질문을 차례로 던져 보시면 돼요. 셋 중 하나가 비어 있으면 나머지 둘이 아무리 튼튼해도 그 자리가 약한 지점이 돼요. 반대로 세 질문에 답할 수 있다면, 낯선 시스템을 만나도 어디를 먼저 볼지 스스로 정할 수 있어요. 용어를 전부 외우지 않아도 이 세 질문만 손에 쥐고 계시면 충분해요.