모두
모두콘텐츠
얼마 전 회원 수가 많지 않은 사이트의 서버 설정을 점검했는데, 웹서버 성능보다 더 신경 쓰인 건 백업 파일이었습니다. 회원 정보가 들어 있는 데이터베이스 백업이 웹에서 접근 가능한 폴더에 놓여 있었거든요. 트래픽은 하루 몇백 명 수준이었지만, 개인정보보안 위험은 방문자 수와 비례하지 않습니다. 작은 사이트일수록 누가 데이터를 저장하고, 어디에 복사하며, 어떻게 지우는지부터 확인하는 편이 낫습니다.
서버 사양보다 저장 위치를 먼저 확인합니다
개인정보가 들어가는 곳은 회원 데이터베이스만이 아닙니다. 문의 폼의 첨부 파일, 관리자에게 발송한 알림 메일, 오류 로그, 엑셀 내보내기 파일에도 이름과 연락처가 남습니다. 운영자가 데이터베이스만 보호했다고 생각하는 사이 임시 파일이 더 오래 남아 있는 경우가 있습니다.
처음에는 수집 항목별로 저장 위치와 보관 기간을 적어 두는 게 좋습니다. 예를 들어 문의 접수에 이름과 이메일만 필요하다면 전화번호 입력란은 없애는 식입니다. 저장하지 않은 정보는 유출될 수도, 백업에서 찾아 지워야 할 일도 없습니다. 테스트용으로 받은 실제 고객 정보를 개발 서버에 복사하는 습관도 끊어야 합니다.
웹호스팅을 쓰든 VPS를 쓰든 원칙은 같습니다. 업로드 파일과 백업 파일은 공개 폴더 밖에 두고, 서버 설정 파일에는 필요한 계정만 접근하게 합니다. VPS는 설정을 세밀하게 바꿀 수 있지만 운영자가 권한과 업데이트를 직접 챙겨야 합니다. 회원이 하루 30명 가입하는 사이트라면 서버를 키우는 것보다 현재 저장 경로부터 확인하는 일이 먼저입니다.
관리자 계정과 접속 경로를 좁힙니다
서버 침입이 의심될 때 가장 먼저 보는 것 중 하나가 관리자 계정입니다. 여러 사람이 계정 하나를 공유하면 누가 언제 설정을 바꿨는지 추적하기 어렵습니다. 호스팅 관리 화면, 서버 접속 계정, 데이터베이스 계정을 구분하고 담당자마다 필요한 권한만 줍니다. 퇴사자나 외주 작업자의 계정은 작업이 끝난 날 회수할 수 있어야 합니다.
관리 화면에는 다중 인증을 켜고, 복구 코드도 접근 권한이 제한된 곳에 보관합니다. 데이터베이스 계정을 애플리케이션과 관리자 작업에 함께 쓰지 않는 편이 좋습니다. 평소 글을 조회하고 수정하는 프로그램에 전체 데이터베이스를 삭제할 권한까지 줄 이유는 거의 없습니다. 비밀번호와 접속 키는 소스 코드나 배포 로그에 남기지 않고, 노출이 확인되면 해당 키를 교체합니다.
SSL 인증서는 브라우저와 서버 사이의 전송을 보호합니다. 하지만 인증서가 정상이어도 관리자 비밀번호가 유출되거나 서버 안의 백업 파일이 공개되어 있으면 개인정보는 안전하지 않습니다. 인증서 만료 알림을 설정하는 일과 계정 권한을 점검하는 일은 함께 가야 합니다.
로그에는 사고 단서를 남기고 개인정보는 줄입니다
장애가 나면 로그가 필요합니다. 그렇다고 요청 내용 전체를 기록하면 문의 메시지, 비밀번호, 인증 토큰까지 로그에 복사될 수 있습니다. OWASP의 로깅 지침도 민감한 개인정보와 인증 정보를 그대로 기록하지 않도록 권고합니다. 오류를 추적하는 데 필요한 시각, 요청 식별값, 처리 결과는 남기되 입력값은 항목별로 가리거나 제외합니다.
운영 중에는 정상 요청이 많은 로그보다 평소와 다른 흐름을 먼저 봅니다. 짧은 시간에 관리자 로그인 실패가 반복되는지, 회원 정보 내보내기 기능이 갑자기 많이 실행됐는지, 백업 저장소에 낯선 접근이 있었는지를 확인합니다. 예를 들어 평소 하루 한 번도 쓰지 않던 내보내기 기능이 10분 동안 20번 실행됐다면 조사할 만합니다. 이 숫자는 보편적인 경보 기준이 아니라 해당 사이트의 평소 사용량과 비교하기 위한 예시입니다.
로그 자체에도 접근 권한과 보관 기간이 필요합니다. 서버의 모든 로그를 무기한 쌓아 두면 사고 조사 자료가 늘어나는 동시에 보호해야 할 개인정보도 늘어납니다.
백업은 복원해 봐야 믿을 수 있습니다
백업 작업이 성공으로 표시돼도 복원이 된다는 뜻은 아닙니다. 데이터베이스 파일은 있는데 첨부 파일이 빠져 있거나, 암호화한 백업의 복호화 키를 찾지 못하는 일이 생깁니다. 회원 정보가 수시로 바뀌는 사이트라면 하루 한 번 백업할 때 최대 하루치 변경분을 잃을 수 있다는 점부터 계산해야 합니다. 주문이나 예약처럼 손실 허용 시간이 짧은 데이터는 백업 간격도 그에 맞춰 줄입니다.
운영 서버와 같은 계정으로 접근하는 저장 공간에만 백업을 두면 계정 하나가 뚫렸을 때 원본과 백업이 함께 위험해집니다. 백업은 접근 권한을 따로 제한하고 암호화한 뒤, 별도 저장 위치에도 보관합니다. 한 달에 한 번 정도는 격리된 환경에서 데이터베이스와 파일을 함께 복원해 화면과 주요 기능이 작동하는지 확인할 만합니다. 복원에 걸린 시간도 기록해 두면 장애 때 예상 시간을 말할 수 있습니다.
개인정보보안 때문에 무조건 비싼 클라우드 요금제가 필요한 건 아닙니다. 저가 웹호스팅에서도 수집 항목을 줄이고, 관리자 권한을 관리하고, 백업을 따로 보관할 수 있습니다. 제가 운영 현장에서 더 신뢰하는 건 서버 가격표보다 마지막 복원 시험 날짜와 계정 목록이 적힌 운영 기록입니다.
