보안 담당자가 ‘나’ 한 명뿐이라면
회사에 다니면 보안은 어느 정도 누군가 챙겨주잖아요. 노트북엔 보안 에이전트가 깔려 있고, 사내 계정엔 2단계 인증이 강제되고, 수상한 메일이 오면 보안팀이 경고를 보내주죠. 그런데 프리랜서나 1인 개발사, 사이드 프로젝트로 작은 SaaS를 운영하는 분들은 사정이 달라요. 개발자이자 영업 담당이자 회계 담당이면서 보안 담당자까지 혼자 맡고 있거든요.
미국 국립표준기술연구소 NIST가 바로 이런 분들을 위한 사이버보안 가이드를 내놓았어요. NIST는 미국의 각종 기술 표준을 만드는 정부 기관이에요. 개발자들에게는 보안 프레임워크 NIST CSF, 그리고 “비밀번호 주기적 강제 변경은 하지 말라”는 권고가 담긴 디지털 신원 가이드라인(SP 800-63)으로 익숙하죠. 그동안 NIST 자료는 기업이나 기관 대상이 많아서 1인 사업자가 읽기엔 너무 무거웠어요. 이번 가이드는 자영업자와 솔로프리너(혼자 사업을 운영하는 사람)를 콕 집어 대상으로 삼았다는 점이 포인트예요.
왜 1인 사업자가 표적이 될까
“나 같은 작은 사업자를 누가 노리겠어?” 싶지만, 공격자 입장에선 오히려 좋은 먹잇감이에요. 지켜줄 보안팀이 없고, 개인 계정과 업무 계정이 뒤섞여 있어서 하나만 뚫으면 줄줄이 따라오거든요. 특히 개발 프리랜서는 클라이언트의 서버, 저장소, 클라우드 콘솔에 접근 권한을 갖고 있는 경우가 많아요. 그래서 프리랜서 한 명이 털리면 클라이언트 회사까지 뚫리는 공급망 공격의 입구가 될 수 있어요.
여섯 가지 기능으로 내 보안 점검하기
NIST는 소규모 사업자용 자료를 만들 때 CSF 2.0의 여섯 가지 기능을 뼈대로 써왔어요. 이 틀에 맞춰 1인 개발자가 챙겨야 할 것들을 풀어볼게요.
거버넌스(Govern)는 거창하게 들리지만, 결국 내가 어떤 보안 책임을 지고 있는지 아는 거예요. 클라이언트 계약서에 보안 조항이 있는지, 고객 개인정보를 다루는지부터 정리해보세요.
식별(Identify)은 지켜야 할 자산의 목록을 만드는 단계예요. 노트북, 휴대폰, 업무 이메일, 도메인 등록 계정, GitHub, 클라우드 계정, 결제 계정, 그리고 여기저기 흩어진 API 키까지 적어보세요. 목록에 없는 건 지킬 수도 없거든요.
보호(Protect)는 가장 실천적인 부분이에요. 중요한 계정에는 전부 다중 인증(MFA)을 켜세요. 가능하면 문자 인증보다 OTP 앱, 패스키, 하드웨어 보안 키를 쓰는 게 좋아요. 비밀번호 관리자로 계정마다 다른 비밀번호를 쓰고, OS와 브라우저 업데이트는 미루지 말고, 노트북 디스크 암호화(FileVault, BitLocker)도 켜두세요.
탐지(Detect)는 이상 징후를 알아채는 장치예요. 새 기기 로그인 알림, 클라우드 예산 알람, GitHub 시크릿 스캐닝 같은 걸 켜두면 큰 사고를 초기에 잡을 수 있어요.
대응(Respond)은 털렸을 때 뭘 먼저 할지 미리 적어두는 거예요. 비밀번호를 바꿀 순서, 키를 폐기하는 방법, 클라이언트에게 알리는 방법까지요. 사고가 나면 머리가 하얘지니까 미리 적어둔 메모 한 장이 큰 차이를 만들어요.
복구(Recover)는 결국 백업이에요. 데이터 사본을 3개 만들고, 2가지 다른 매체에 저장하고, 그중 1개는 외부에 두는 3-2-1 백업 원칙을 기억해두세요. 랜섬웨어에 걸려도 백업만 살아 있으면 다시 일어설 수 있어요.
개발자라면 특히 조심할 것들
개발자에게만 있는 위험도 있어요. 첫째는 이메일 계정이에요. 거의 모든 서비스의 비밀번호 재설정 메일이 여기로 오니까, 이메일은 사실상 모든 계정의 마스터 키예요. 둘째는 도메인 등록 계정이에요. 여기가 털리면 공격자가 DNS를 바꿔서 서비스 전체를 가로챌 수 있어요. 셋째는 .env 파일이나 API 키를 공개 저장소에 실수로 커밋하는 사고예요. 봇들이 공개 저장소를 늘 훑고 있어서, 올라가는 순간 몇 분 만에 악용될 수 있어요.
한국 개발자에게 주는 시사점
국내에도 참고할 자료가 있어요. KISA(한국인터넷진흥원)는 보호나라를 통해 중소기업과 개인을 위한 보안 가이드와 점검 서비스를 제공해요. 그리고 꼭 기억해야 할 게 있어요. 우리나라 개인정보보호법은 1인 사업자에게도 적용돼요. 작은 서비스라도 회원 정보를 받고 있다면 안전성 확보 조치 의무가 생겨요.
크몽이나 위시켓으로 외주 개발을 하시는 분들은 평소 관행도 점검해보세요. 카톡으로 서버 비밀번호를 주고받거나, 프로젝트가 끝난 뒤에도 클라이언트 계정 권한을 그대로 갖고 있는 경우가 많거든요. 프로젝트 종료 시 권한을 반납하는 절차를 계약에 넣는 것만으로도 서로를 지킬 수 있어요.
마무리
한 줄 정리: 보안팀이 없다면 내가 보안팀이에요. 거창한 솔루션보다 MFA, 비밀번호 관리자, 백업, 이 세 가지 기본기가 1인 사업자를 지켜줘요.
프리랜서 일이나 사이드 프로젝트를 하다가 보안 때문에 아찔했던 경험이 있으신가요? 평소 쓰는 보안 루틴이 있다면 공유해주세요!
🔗 출처: Hacker News