얼마 전 작은 온라인 쇼핑몰을 운영하는 지인과 이야기하다가 클라우드보안 이야기가 나왔습니다. 서버를 직접 들고 있지 않으니 훨씬 편해졌다고 말하더니, 바로 다음 말이 “그럼 보안도 알아서 되는 거 아니야?”였거든요. 사실 여기서부터 오해가 생깁니다. 클라우드 업체가 건물, 장비, 기본 인프라는 튼튼하게 지켜주지만, 계정 설정이나 데이터 접근 권한, 백업 방식 같은 부분은 사용자가 챙겨야 합니다.
클라우드는 편리한 만큼 문이 많습니다. 관리 콘솔, API 키, 저장소, 데이터베이스, 가상 서버, 협업 계정까지 연결점이 늘어나죠. 문이 많으면 잠금장치도 많아야 합니다. 어렵게 느껴질 수 있지만, 처음부터 거창한 보안 체계를 만들 필요는 없습니다. 자주 터지는 실수를 먼저 막는 것만으로도 위험은 꽤 줄어듭니다.
계정부터 단단하게 잠그기
클라우드보안에서 가장 먼저 볼 부분은 계정입니다. 의외로 침해 사고는 복잡한 해킹 기술보다 약한 비밀번호, 공유 계정, 방치된 관리자 계정에서 시작되는 경우가 많습니다. 특히 관리자 권한 계정 하나가 뚫리면 서버 생성, 데이터 삭제, 비용 폭탄까지 이어질 수 있어요.
관리자 계정은 평소 업무용으로 쓰지 않는 편이 좋습니다. 일상적인 작업은 권한을 낮춘 계정으로 하고, 정말 필요한 순간에만 관리자 권한을 쓰는 식입니다. 여기에 다중 인증을 켜면 체감 보안이 확 올라갑니다. 비밀번호가 새어 나가도 휴대폰 인증이나 보안 키가 없으면 바로 들어오기 어렵기 때문입니다.
- 관리자 계정에는 반드시 다중 인증을 적용합니다.
- 직원별로 개인 계정을 만들고 공유 계정 사용을 줄입니다.
- 퇴사자, 외주 작업자, 테스트 계정은 작업 종료 후 바로 비활성화합니다.
- 권한은 처음부터 넓게 주지 말고 필요한 범위만 부여합니다.
실무에서는 “나중에 줄이면 되지” 하며 권한을 넓게 주는 일이 많습니다. 그런데 나중은 잘 오지 않습니다. 처음부터 좁게 주고, 필요한 순간에 승인해서 넓히는 방식이 훨씬 관리하기 편합니다.
저장소와 데이터 공개 설정 확인하기
클라우드에서 자주 나오는 사고 중 하나가 저장소 공개 설정 문제입니다. 내부용 파일, 백업 파일, 고객 정보가 담긴 자료가 외부에서 열리는 상태로 남아 있는 경우죠. 누구나 볼 수 있는 공개 저장소는 이미지 배포나 다운로드 자료 제공에는 편하지만, 실수로 민감한 파일이 들어가면 바로 위험해집니다.
예를 들어 개발자가 테스트용으로 만든 저장 공간에 주문 내역 샘플을 올려두고, 임시 공개 설정을 그대로 둔다면 문제가 됩니다. 파일 이름이 복잡하다고 안전한 것도 아닙니다. 자동 스캔 도구는 이런 노출을 생각보다 빠르게 찾아냅니다.
공개가 필요한 것과 아닌 것을 나누기
저장소는 용도별로 나누는 게 좋습니다. 웹사이트 이미지처럼 외부 공개가 필요한 저장소와, 로그나 백업처럼 내부에서만 봐야 하는 저장소를 섞지 않는 방식입니다. 이렇게만 해도 실수의 범위가 줄어듭니다.
- 고객 정보, 계약서, 백업 파일은 기본적으로 비공개로 둡니다.
- 공개 저장소에는 공개 가능한 파일만 올라가도록 배포 과정을 분리합니다.
- 저장소 정책을 바꾼 뒤에는 실제로 외부 접근이 되는지 테스트합니다.
- 중요 데이터는 암호화를 켜고, 암호화 키 접근 권한도 따로 관리합니다.
민감한 데이터는 저장할 때부터 줄이는 습관도 중요합니다. 필요 없는 개인정보를 오래 보관하면 지켜야 할 짐만 늘어납니다. “혹시 몰라서” 쌓아둔 데이터가 나중에는 가장 부담스러운 대상이 되기도 합니다.
로그와 알림을 켜두기
보안 사고에서 무서운 점은 사고가 난 사실을 늦게 안다는 겁니다. 클라우드 비용이 갑자기 늘었거나, 고객 문의가 들어오거나, 서비스가 느려진 뒤에야 이상을 느끼는 경우도 있습니다. 그래서 로그와 알림은 선택이 아니라 기본에 가깝습니다.
로그는 누가, 언제, 어디서, 무엇을 했는지 남기는 기록입니다. 관리자 로그인, 권한 변경, 서버 생성, 저장소 공개 전환 같은 이벤트는 꼭 남겨야 합니다. 로그가 없으면 사고가 생긴 뒤에도 원인을 찾기 어렵습니다. 반대로 로그가 잘 남아 있으면 피해 범위를 빨리 좁힐 수 있습니다.
- 관리자 로그인 실패가 반복되면 알림을 받도록 설정합니다.
- 새로운 관리자 권한이 부여되면 담당자에게 알립니다.
- 평소보다 많은 데이터 다운로드가 발생하면 확인합니다.
- 갑작스러운 서버 생성이나 해외 리전 사용도 알림 대상으로 둡니다.
처음부터 모든 알림을 켜면 알림이 너무 많아져서 오히려 안 보게 됩니다. 그래서 비용, 권한, 데이터 접근처럼 큰 피해로 이어질 수 있는 항목부터 시작하는 편이 현실적입니다. 한 달 정도 운영하면서 너무 시끄러운 알림은 기준을 조절하면 됩니다.
백업과 복구를 실제로 테스트하기
백업은 “있다”보다 “복구된다”가 중요합니다. 백업 파일은 있는데 복구 절차를 아무도 모르거나, 복구 시간이 너무 길어서 서비스 운영에 맞지 않는 경우가 꽤 있습니다. 클라우드는 스냅샷, 자동 백업, 버전 관리 같은 기능을 제공하지만 설정만 해두고 끝내면 안심하기 이릅니다.
예를 들어 하루에 한 번 백업되는 데이터베이스라면 최악의 경우 하루치 주문이나 문의가 사라질 수 있습니다. 그 정도 손실을 감당할 수 있는지 먼저 생각해야 합니다. 쇼핑몰, 예약 서비스, 병원 업무처럼 데이터가 계속 쌓이는 서비스라면 백업 주기를 더 촘촘하게 잡는 게 낫습니다.
복구 연습이 필요한 이유
복구 연습은 생각보다 많은 것을 알려줍니다. 백업 파일 위치를 누가 아는지, 권한은 충분한지, 복구 후 앱 설정이 맞는지, 실제 걸리는 시간이 어느 정도인지 확인할 수 있습니다. 문서로만 적힌 절차와 실제 손으로 해본 절차는 다릅니다.
- 중요 데이터는 자동 백업을 켜고 보관 기간을 정합니다.
- 월 1회 정도 테스트 환경에서 복구를 연습합니다.
- 랜섬웨어에 대비해 삭제 방지나 버전 관리 기능을 검토합니다.
- 백업 접근 권한은 운영 권한과 분리합니다.
백업은 보험과 비슷합니다. 평소에는 조용하지만, 문제가 생겼을 때 회사의 하루를 살려줍니다. 비용을 아끼려고 백업을 너무 짧게 가져가면 작은 실수가 큰 손실이 될 수 있습니다.
처음 시작할 때 체크하면 좋은 순서
클라우드보안을 어렵게 느끼는 이유는 범위가 넓기 때문입니다. 계정, 네트워크, 데이터, 비용, 개발 방식, 협업 도구까지 이어지니까요. 그래서 처음에는 모든 걸 완벽하게 하려 하기보다 우선순위를 잡는 게 좋습니다.
개인 프로젝트나 작은 회사라면 계정 보안, 공개 설정, 백업, 로그 네 가지부터 잡아도 효과가 큽니다. 이후 서비스가 커지면 네트워크 분리, 취약점 점검, 보안 정책 자동화, 개발 배포 과정의 비밀값 관리까지 넓혀가면 됩니다.
- 1단계: 관리자 계정 다중 인증과 개인별 계정 분리
- 2단계: 저장소와 데이터베이스 공개 여부 점검
- 3단계: 주요 활동 로그 저장과 알림 설정
- 4단계: 백업 주기 설정과 복구 테스트
- 5단계: API 키, 비밀값, 접근 토큰 관리 방식 개선
근데 여기서 꼭 기억할 점이 있습니다. 보안은 한 번 설정하고 끝나는 작업이 아닙니다. 새 직원이 들어오고, 외주사가 붙고, 기능이 추가되고, 테스트 서버가 생길 때마다 작은 구멍이 생길 수 있습니다. 그래서 분기마다 한 번씩 계정과 권한, 공개 저장소, 오래된 키를 확인하는 날을 잡아두면 좋습니다.
클라우드보안은 거창한 장비나 어려운 용어에서 시작하지 않아도 됩니다. 내 계정이 안전한지, 공개되면 안 되는 데이터가 열려 있지 않은지, 문제가 생겼을 때 기록과 백업이 남는지부터 보면 됩니다. 이런 기본기가 쌓이면 클라우드는 훨씬 든든한 도구가 됩니다. 편리함을 누리면서도 불안은 줄이는 쪽으로, 조금씩 손에 익혀가는 방식이 가장 현실적이라고 느낍니다.
