회원 개인정보, 어떻게 저장해야 안전할까

데이터 유형별로 저장 방식이 다릅니다

모든 정보를 똑같이 저장하면 안 됩니다. 되돌릴 필요가 있는지, 아예 안 받아도 되는지에 따라 방식이 갈립니다.

데이터 유형별 올바른 저장 방식

주민등록번호

원칙적으로 미수집

비밀번호

단방향 해시(bcrypt)

연락처·주소·생년월일

양방향 암호화(AES-256)

닉네임 등 일반정보

일반 저장 + 접근 제한

막대 길이는 ‘되돌려 쓸 수 있는 정도’를 나타냅니다. 비밀번호는 되돌릴 수 없게(해시), 민감정보는 되돌려 쓰되 암호화합니다.

수집한 정보가 없으면 샐 것도 없습니다. 법적 근거 없이 주민등록번호는 받지 않습니다. 본인확인이 필요하면 본인확인기관(휴대폰 인증 등)을 쓰고, 그 결과값만 보관합니다. 서비스에 꼭 필요한 최소 항목만 받는 것이 원칙이자 가장 확실한 보안입니다.

비밀번호는 해시로 저장합니다. 관리자가 원문을 볼 수 있으면 위험합니다. bcrypt 같은 검증된 방식으로 해시하고, 절대 평문·양방향 암호로 저장하지 않습니다.

const bcrypt = require('bcryptjs');
const hash = await bcrypt.hash(password, 10);   // 저장
const ok   = await bcrypt.compare(input, hash); // 검증

연락처·주소·생년월일처럼 되돌려 써야 하는 정보는 AES-256 같은 양방향 암호화로 저장합니다. 키는 코드가 아니라 별도 비밀 저장소(환경변수·시크릿 매니저)에 둡니다. 키 관리가 곧 암호화의 핵심입니다(관련: 키를 안전하게 두는 법).

한눈에 비교

정기 백업을 두되, 백업도 암호화합니다(관련: 백업 전략). 그리고 보관 기간이 지난 데이터·탈퇴 회원 데이터는 정해진 절차로 파기합니다. 수집만 하고 안 지우면 위험이 계속 쌓입니다.

참고: 본 글은 실무 보안 안내이며, 개인정보보호법 등 법적 의무의 구체 판단은 전문가 상담을 권합니다.

주민등록번호를 꼭 받아야 하는 서비스라면요?

법적 근거가 있는 경우에만 수집·암호화 저장이 허용됩니다. 대부분은 본인확인기관을 통해 대체할 수 있습니다.

Firebase에서도 암호화해야 하나요?

전송·저장이 기본 암호화되지만, 민감 필드는 추가 암호화와 보안 규칙으로 접근을 제한하는 것이 안전합니다.

비밀번호도 AES로 암호화하면 안 되나요?

비밀번호는 되돌릴 필요가 없으므로 양방향 암호(AES)가 아니라 단방향 해시(bcrypt 등)로 저장해야 합니다. 암호화는 키가 유출되면 원문이 복원되지만, 해시는 원문 복원이 설계상 불가능해 더 안전합니다.

우리 서비스 점검을 맡길 수 있나요?

수집 항목, 비밀번호 저장 방식, 암호화, 접근 권한, 백업을 점검해 위험도별 리포트를 드립니다.

수집 항목·저장 방식만 알려주셔도 어디가 위험한지 먼저 짚어 드립니다.

문의: appmonster.kr@gmail.com