보안은 기능이 아니라 신뢰의 조건이다
보안은 개발자나 보안 전문가만 신경 쓰는 특별한 영역처럼 보일 때가 많다. 하지만 실제로는 서비스를 쓰는 모든 사람과 서비스를 운영하는 모든 조직의 문제다. 사용자는 로그인할 때 비밀번호를 맡긴다. 주소를 입력하고, 결제를 하고, 때로는 주민등록번호나 건강 정보처럼 민감한 정보를 제공한다. 이때 사용자가 기대하는 것은 단순하다. "내 정보가 함부로 새어 나가지 않겠지."
서비스가 아무리 편리해도 이 믿음이 깨지면 사용자는 떠난다. 더 큰 문제는 피해가 서비스 안에서 끝나지 않는다는 점이다. 한 쇼핑몰에서 유출된 이메일과 비밀번호가 다른 서비스 로그인 시도에 사용될 수 있다. 배송지가 스팸이나 사기에 악용될 수 있다. 회사 내부 자료가 새어 나가면 고객뿐 아니라 직원과 협력사까지 피해를 입는다.
그래서 보안은 '나중에 여유가 있을 때 추가하는 기능'이 아니다. 로그인, 결제, 개인정보 입력, 관리자 페이지처럼 중요한 부분을 만들 때 처음부터 함께 고려해야 하는 기본 조건이다.
AI 생성 이미지
비밀번호는 그대로 저장하면 안 된다
가장 흔하면서도 중요한 예가 비밀번호다. 회원가입을 하면 사용자가 입력한 비밀번호가 서버로 전달된다. 이때 서비스를 만드는 쪽에서 절대 해서는 안 되는 일이 있다. 비밀번호를 그대로 저장하는 것이다.
예를 들어 데이터베이스에 다음과 같이 저장되어 있다고 생각해 보자.
이메일: [email protected]
비밀번호: apple1234
이 상태에서 데이터베이스가 유출되면 공격자는 사용자의 비밀번호를 바로 알 수 있다. 더 위험한 점은 많은 사람이 여러 서비스에서 같은 비밀번호를 반복해서 쓴다는 것이다. 한 서비스의 실수가 다른 은행, 이메일, 쇼핑몰 계정의 위험으로 이어질 수 있다.
그래서 비밀번호는 보통 그대로 저장하지 않는다. 여기서 자주 나오는 말이 암호화와 해시다.
암호화는 자물쇠가 달린 상자에 넣는 것과 비슷하다. 열쇠가 있으면 원래 내용을 다시 꺼낼 수 있다. 예를 들어 중요한 문서를 암호화해 저장해 두면, 권한 있는 사람이 열쇠에 해당하는 값을 사용해 다시 읽을 수 있다.
반면 해시는 재료를 갈아 만든 반죽에 가깝다. 원래 재료가 무엇인지 정확히 되돌리기 어렵다. 비밀번호 보관에서는 보통 이 해시 방식을 쓴다. 사용자가 입력한 비밀번호를 일정한 규칙으로 바꾼 값만 저장하고, 다음 로그인 때도 입력값을 같은 방식으로 바꿔 저장된 값과 비교한다. 서버는 "같은 비밀번호인지"는 확인하지만, 원래 비밀번호를 직접 보관하지 않는다.
여기에 솔트라는 개념도 함께 쓰인다. 솔트는 비밀번호에 섞는 추가 재료다. 같은 비밀번호를 쓰더라도 사람마다 다른 해시 값이 나오게 만들어 공격자가 미리 준비한 목록으로 쉽게 맞히지 못하게 한다. 일반 이용자가 이 기술을 직접 구현할 필요는 없지만, 운영자라면 "비밀번호를 평문으로 저장하지 않는다"는 원칙만큼은 반드시 확인해야 한다.
로그인, 인증, 인가는 서로 다르다
보안을 이해할 때 많이 헷갈리는 말이 로그인, 인증, 인가다. 비슷해 보이지만 해결하는 문제가 다르다.
로그인은 사용자가 서비스에 들어가기 위해 이메일과 비밀번호, 휴대폰 인증, 소셜 계정 등을 제출하는 행동이다. 문 앞에서 신분증을 보여 주는 장면과 비슷하다.
인증은 "당신이 정말 그 사람이 맞는가?"를 확인하는 과정이다. OWASP는 인증을 어떤 개인이나 서비스가 주장하는 정체가 맞는지 확인하는 과정으로 설명한다1. 비밀번호 확인, 문자 인증번호, 지문, 얼굴 인식, 일회용 인증 앱 등이 모두 인증에 쓰일 수 있다.
인가는 "확인된 이 사람이 무엇을 할 수 있는가?"를 결정하는 과정이다. 회사 건물 출입증을 예로 들면 이해하기 쉽다. 출입증이 진짜인지 확인하는 것은 인증이다. 그 출입증으로 사무실, 회의실, 서버실 중 어디까지 들어갈 수 있는지 정하는 것은 인가다.
서비스에서도 마찬가지다.
일반 회원은 자기 주문 내역만 볼 수 있다.
판매자는 자기 상품의 주문 내역을 볼 수 있다.
관리자는 전체 회원과 주문 정보를 볼 수 있다.
고객센터 직원은 상담에 필요한 일부 정보만 볼 수 있다.
여기서 중요한 것은 "로그인했으니 모든 것을 할 수 있다"가 아니라는 점이다. 로그인은 출발점일 뿐이다. 로그인한 사용자가 어떤 데이터에 접근할 수 있는지, 어떤 버튼을 누를 수 있는지, 어떤 수정 권한을 가지는지는 따로 관리해야 한다.
특히 관리자 페이지는 주의해야 한다. 일반 사용자 화면에는 보이지 않아도 주소만 알면 접근되는 경우가 있다. 이런 구조는 위험하다. 화면에서 버튼을 숨기는 것만으로는 충분하지 않다. 서버가 매번 "이 사용자가 이 작업을 해도 되는가?"를 확인해야 한다.
개인정보는 적게 모을수록 안전하다
개인정보 보호의 첫 번째 원칙은 의외로 단순하다. 필요하지 않은 정보는 모으지 않는 것이다.
서비스를 만들다 보면 "나중에 쓸 수도 있으니 일단 받아 두자"는 생각을 하기 쉽다. 생년월일, 성별, 주소, 직업, 관심사, 전화번호를 모두 입력받으면 언젠가 마케팅에 도움이 될 것처럼 보인다. 하지만 모은 정보는 모두 책임이 된다. 가지고 있지 않은 정보는 유출될 수 없다.
예를 들어 뉴스레터 구독 서비스라면 이메일 주소만으로 충분할 수 있다. 배송이 없는 디지털 서비스라면 집주소를 받을 이유가 없다. 성인 인증이 필요한 서비스라 해도 생년월일 전체를 계속 보관해야 하는지, 인증 결과만 보관하면 되는지 따져 보아야 한다.
데이터 보안은 디지털 정보를 무단 접근, 훼손, 도난으로부터 보호하는 활동이다2. 여기에는 암호화, 접근 제어, 모니터링, 백업 같은 여러 장치가 포함된다. 하지만 가장 앞단에는 "어떤 데이터를 왜 모으는가"라는 질문이 있어야 한다.
개인정보는 수집보다 관리가 더 어렵다. 누가 볼 수 있는지, 어디에 저장되는지, 언제 삭제되는지, 외부 업체와 공유되는지 계속 관리해야 한다. 그래서 개인정보 보호에서는 수집을 최소화하고, 필요한 사람만 접근하게 하며, 더 이상 필요하지 않은 정보는 삭제하는 원칙이 중요하다3.
접근 권한은 내부에서도 나누어야 한다
많은 사람이 보안을 외부 해커를 막는 일로만 생각한다. 물론 외부 공격을 막는 것도 중요하다. 하지만 실제 서비스 운영에서는 내부 접근 관리도 그만큼 중요하다.
예를 들어 고객센터 직원이 상담을 위해 고객 이름과 주문 상태를 볼 필요는 있을 수 있다. 그러나 모든 고객의 결제 정보나 비밀번호 관련 정보를 볼 필요는 없다. 마케팅 담당자가 통계는 볼 수 있어도 개별 사용자의 민감한 기록까지 볼 필요는 없을 수 있다.
이런 원칙을 최소 권한이라고 한다. 각 사람과 시스템이 자기 일을 하는 데 필요한 만큼만 권한을 갖게 하는 방식이다. 마트 직원 모두에게 금고 열쇠를 주지 않는 것과 같다. 계산대 직원, 매장 관리자, 창고 담당자가 필요한 열쇠가 다르듯 서비스 안에서도 역할별 권한이 달라야 한다.
접근 권한 관리는 불편함을 만들기 위한 장치가 아니다. 실수를 줄이기 위한 장치다. 권한이 넓으면 한 사람의 계정이 탈취되었을 때 피해도 커진다. 반대로 권한을 나누어 두면 사고가 나더라도 피해 범위를 줄일 수 있다.
피싱, 악성코드, 데이터 유출은 현실의 피해로 이어진다
보안 사고는 영화처럼 복잡한 해킹 장면으로만 일어나지 않는다. 매우 평범한 방식으로 시작되는 경우가 많다.
피싱은 가짜 메시지나 가짜 사이트로 사용자를 속이는 공격이다. "택배 주소를 확인하세요", "계정이 정지됩니다", "결제 오류가 발생했습니다" 같은 문구로 링크를 누르게 만든다. 사용자가 진짜 사이트라고 믿고 아이디와 비밀번호를 입력하면 공격자는 그 정보를 가져간다.
악성코드는 사용자의 기기나 회사 컴퓨터에 몰래 설치되어 정보를 훔치거나 파일을 잠그거나 원격 조종을 가능하게 하는 프로그램이다. 이메일 첨부파일, 불법 프로그램, 가짜 업데이트 파일을 통해 들어올 수 있다. 한 직원의 컴퓨터 감염이 회사 전체 시스템 침해로 이어질 수도 있다.
데이터 유출은 서비스가 보관하던 정보가 허가 없이 외부로 나가는 일이다. 이메일, 전화번호, 주소, 주문 내역, 상담 기록, 결제 관련 정보가 유출되면 사용자는 스팸, 사기, 명의 도용, 추가 피싱 공격에 노출될 수 있다. 운영자는 법적 책임, 보상 비용, 신뢰 하락, 서비스 중단 같은 피해를 겪는다.
웹서비스는 사용자가 보낸 입력값, 브라우저, 외부 서비스와의 연결을 무조건 믿어서는 안 된다. 겉보기에는 정상 사용자의 요청처럼 보여도 공격자가 조작한 값일 수 있기 때문이다4. 그래서 서버는 입력값을 확인하고, 권한을 검사하고, 이상한 행동을 기록하고, 민감한 작업에는 추가 확인을 요구해야 한다.
보안을 어렵게만 볼 필요는 없다
보안을 완벽하게 이해하려고 하면 금방 지친다. 암호학, 네트워크, 운영체제, 법률, 클라우드 설정까지 범위가 넓기 때문이다. 하지만 일반 이용자와 운영자가 먼저 알아야 할 원칙은 비교적 분명하다.
이용자라면 다음을 기억하면 좋다.
여러 서비스에서 같은 비밀번호를 반복해 쓰지 않는다.
가능하면 2단계 인증을 켠다.
문자나 이메일의 링크를 누르기 전에 주소와 발신자를 확인한다.
수상한 첨부파일이나 프로그램을 실행하지 않는다.
개인정보 입력이 과도하다고 느껴지면 왜 필요한지 확인한다.
운영자라면 다음을 기본으로 삼아야 한다.
비밀번호를 평문으로 저장하지 않는다.
로그인과 권한 검사를 분리해서 설계한다.
개인정보는 필요한 만큼만 수집한다.
직원과 시스템의 접근 권한을 역할별로 제한한다.
오류, 이상 로그인, 대량 조회 같은 위험 신호를 기록하고 점검한다.
사고가 났을 때 알림, 차단, 복구, 사용자 안내 절차를 준비한다.
보안은 한 번 설정하고 끝나는 일이 아니다. 서비스가 바뀌고, 사용자가 늘고, 새로운 공격 방식이 생기면 계속 점검해야 한다. 그렇다고 겁먹을 필요는 없다. 핵심은 모든 위험을 한 번에 없애는 것이 아니라, 중요한 정보를 알아보고, 접근을 줄이고, 실수를 막고, 사고가 나더라도 피해를 줄이는 방향으로 꾸준히 관리하는 것이다.
보안과 개인정보 보호는 서비스의 뒷문에 붙은 자물쇠가 아니다. 사용자가 안심하고 문을 열 수 있게 만드는 기본 약속이다.
참고
1Authentication - OWASP Cheat Sheet Series
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.