인증·인가·암호화, 각자 맡은 일이 다르다
셋 다 '보호'라는 말로 묶이지만 답하는 질문이 서로 다릅니다. 역할 분담과 서로 대신해 줄 수 없는 지점을 정리합니다.
로그인만 통과하면 끝이라는 착각
인증, 인가, 암호화는 보안 문서에 가장 자주 등장하는 세 단어이면서, 입문자가 가장 자주 뒤섞는 세 단어이기도 합니다. 셋 다 보호와 관련이 있고 대개 함께 쓰이기 때문에 하나의 큰 덩어리처럼 느껴집니다. 하지만 셋은 서로 다른 질문에 답하는 장치이고, 하나가 다른 하나를 대신해 주지 않습니다.
세 단어를 질문 형태로 바꿔 보면 역할이 선명해집니다. 인증은 '너는 누구인가', 인가는 '너는 무엇을 할 수 있는가', 암호화는 '이 내용을 가로채도 읽을 수 있는가'에 답합니다. 실제 사고 중 상당수는 셋 중 하나가 아예 없어서가 아니라, 하나가 다른 하나까지 해 줄 것이라 믿고 넘어간 자리에서 발생합니다.
인증: 주장하는 신원이 맞는지 확인하기
인증은 접근하려는 상대가 주장하는 신원이 실제로 맞는지 확인하는 과정입니다. 아이디와 비밀번호를 넣는 로그인이 가장 익숙한 형태입니다. 확인에 쓰이는 재료는 크게 세 가지로 나뉩니다. 아는 것(비밀번호, PIN), 가진 것(스마트폰, 보안 토큰, 인증서), 그리고 자신의 특성(지문, 얼굴)입니다. 성격이 다른 재료를 둘 이상 함께 요구하는 것이 다단계 인증입니다.
재료를 겹쳐 쓰는 이유는 각각의 약점이 다르기 때문입니다. 아는 것은 남에게 알려지는 순간 끝이고, 가진 것은 잃어버릴 수 있으며, 특성은 바꿀 수 없다는 점이 장점이자 약점입니다. 서로 다른 성격을 겹치면 하나가 무너져도 나머지가 남습니다. 다만 인증이 확인해 주는 것은 '누구인지'까지이고, 그 사람이 무엇을 해도 되는지는 전혀 알려 주지 않습니다.
인가: 확인된 사람에게 무엇을 허용할지 정하기
인가는 확인된 신원에게 어떤 행동을 허용할지 정하는 단계입니다. 같은 사내 시스템에 로그인해도 인사 담당자는 급여 자료를 볼 수 있고 다른 부서 직원은 볼 수 없다면, 그 차이를 만드는 것이 인가입니다. 인증이 건물 정문을 통과하는 일이라면, 인가는 층마다 방마다 다르게 걸린 출입 권한에 해당합니다.
현장에서 문제가 자주 생기는 지점이 바로 여기입니다. 로그인 화면은 공들여 만들어 두고, 일단 로그인한 사용자라면 무엇이든 요청할 수 있게 열어 두는 경우가 드물지 않습니다. 화면에서 메뉴를 감추는 것과 요청을 처리하는 쪽에서 권한을 검사하는 것은 완전히 다른 일인데, 앞의 것만 해 두고 인가를 했다고 여기기도 합니다. 권한 검사는 실제로 데이터를 꺼내는 자리에서 이뤄져야 의미가 있습니다.
암호화: 읽지 못하게 만들되, 막지는 않는다
암호화는 정보를 정해진 열쇠 없이는 의미를 알 수 없는 형태로 바꾸는 기술입니다. 저장된 데이터를 대상으로 하기도 하고, 오가는 통신을 대상으로 하기도 합니다. 웹 주소에 https가 붙는 것이 통신 구간 암호화의 익숙한 예입니다. 그리고 암호화의 실질적인 핵심은 알고리즘보다 열쇠 관리에 있습니다. 열쇠를 데이터 옆에 함께 보관해 두었다면 자물쇠와 열쇠를 같은 문고리에 걸어 둔 것과 다르지 않습니다.
암호화가 지켜 주지 못하는 영역을 아는 것도 그만큼 중요합니다. 암호화는 정당한 열쇠를 가진 쪽에는 아무런 저항을 하지 않습니다. 권한이 잘못 부여된 계정이 정상 경로로 데이터를 조회하면, 그 데이터는 읽을 수 있는 상태로 그대로 전달됩니다. 통신이 암호화되어 있어도 사용자가 속아서 직접 정보를 입력해 보내면, 암호화는 그 전송을 안전하게 지켜 줄 뿐 잘못된 상대에게 가는 것을 막지 않습니다. 암호화는 인가의 대체품이 아닙니다.
해시는 암호화가 아니다
해시는 암호화와 나란히 언급되지만 목적이 다릅니다. 암호화는 나중에 되돌려 읽는 것을 전제로 한 양방향 변환이고, 해시는 원래 값으로 되돌릴 수 없는 단방향 변환입니다. 같은 입력은 언제나 같은 결과를 내고, 입력이 조금만 달라져도 결과는 완전히 달라집니다. 이 성질 덕분에 값을 저장하지 않고도 값이 같은지 확인할 수 있습니다.
그래서 비밀번호는 암호화가 아니라 해시로 저장하는 것이 원칙입니다. 서비스는 사용자의 비밀번호 원문을 알아야 할 이유가 없고, 입력값의 해시가 저장된 해시와 일치하는지만 확인하면 되기 때문입니다. 파일이 전송 도중 변조되지 않았는지 해시값을 비교해 확인하는 것도 같은 성질을 쓰는 것이며, 이쪽은 기밀성이 아니라 무결성 영역의 활용입니다. '비밀번호를 찾아 원문 그대로 알려 드립니다'라는 안내가 있다면, 그 자체가 설계를 다시 볼 신호로 읽힙니다.
초보자가 자주 하는 실수
- 로그인만 붙여 놓고 보안이 끝났다고 여기기 — 인증은 신원만 확인할 뿐 권한 범위는 정해 주지 않습니다.
- 화면에서 메뉴를 감추는 것으로 인가를 대신하기 — 요청을 처리하는 쪽에서 검사하지 않으면 통제가 아닙니다.
- 암호화를 만능 대책으로 생각하기 — 정당한 열쇠를 가진 잘못된 접근에는 아무 저항도 하지 않습니다.
읽고 나서 체크리스트
- 인증과 인가가 답하는 질문이 어떻게 다른지 말할 수 있다
- 인증 재료 세 가지를 구분하고 다단계 인증의 의미를 설명할 수 있다
- 암호화가 지키는 것과 지키지 못하는 것을 각각 들 수 있다
- 해시와 암호화의 차이를 방향성으로 설명할 수 있다
- 비밀번호를 해시로 저장하는 이유를 안다
자주 묻는 질문
인증과 인가를 영어 약자로 쓰던데 무슨 뜻인가요?
인증(authentication)을 authn, 인가(authorization)를 authz로 줄여 쓰는 관행입니다. 두 단어의 철자가 비슷해 문서에서 혼동되는 일이 잦다 보니 이렇게 구분해 표기합니다. 뜻은 각각 인증과 인가 그대로입니다.
https만 쓰면 개인정보가 안전한가요?
https는 브라우저와 서버 사이를 오가는 구간을 보호합니다. 서버에 도착한 뒤 어떻게 저장되고 누구에게 보이는지는 별개의 문제이며, 그 부분은 인가와 저장 암호화, 접근 기록으로 다뤄야 합니다. 구간 하나가 안전해졌다는 뜻으로 이해하는 것이 정확합니다.
해시로 저장하면 비밀번호는 완전히 안전한가요?
저장 방식 하나로 안전이 결정되지는 않습니다. 짧고 흔한 비밀번호는 해시로 저장돼도 추측에 약하고, 같은 비밀번호를 여러 서비스에 재사용하면 한 곳의 문제가 다른 곳으로 번집니다. 저장은 서비스의 몫이고, 길이와 재사용 여부는 사용자의 몫입니다.
이 글은 입문자 기준으로 이해하기 쉽게 정리한 일반 정보이며, 내용은 운영 과정에서 순차적으로 점검·보완될 수 있습니다. 구체적인 절차나 수치는 해당 기관의 공식 안내를 기준으로 확인해주세요.