[번역] SaaS 스타트업을 위한 보안 101

2024년 5월

원문 — Security 101 for SaaS startups

https://github.com/forter/security-101-for-saas-startups/

첫 상사가 나에게 말해주었으면 좋았을 것들

스타트업에서 어느 시점에 보안 고려 사항과 규정 준수를 검토해야 하는지 궁금하신가요? 어떤 기술 부채는 다음 단계로 연기해야 하고, 어떤 시스템은 지금 당장 강화해야 할까요? 주요 고려 사항은 무엇일까요?

기술 부채는 쌓여가고, 많은 경우 지금보다는 나중에 지불하는 것이 더 쉽습니다. 예를 들어, 사용자 이름/비밀번호 없이 ElasticSearch를 사용하고 있다면 방화벽 설정을 다시 한 번 확인해야 합니다. 시리즈 B가 끝나면 스타트업은 아마도 ElasticSearch 클러스터를 적절히 보호할 수 있는 인력과 예산을 확보하게 될 것입니다.

하지만 스타트업 문화는 나중에 바꾸기가 조금 더 어렵습니다. 사소한 예를 들어보겠습니다. 코드 리뷰 없이 코드를 푸시하는 데 익숙한 개발자는 코드 리뷰가 개발에 방해가 되고 심지어 너무 대기업 같은 느낌이 난다고 불평할 수 있습니다.

그렇다면 초기 단계에서 어떤 보안 고려 사항을 고려해야 할까요?

제품에 비용을 지불할 의향이 있는 고객이 제기한 보안 우려는 무엇인가요?
업계(의료, 금융, 기업)에서 기대하는 보안 수준은 어느 정도인가요?
타겟 시장(국가)의 규제(데이터 개인정보 보호, 데이터 거주지)에는 어떤 것들이 있나요? 유럽은 규제가 더 엄격한 것으로 알려져 있습니다. 미국은 주마다 규정이 다릅니다.
어떤 도구와 정책이 팀의 사기를 해치지 않을까요?
보안 위험 계획을 준비하는 데 얼마나 걸리나요? (문서 하단의 예 참조)
- 지적 재산 도난, 사업 계획 도난, 비트코인/EC2 도난, 모든 데이터 손실이 발생할 경우 얼마나 큰 영향이 있나요? 매출, 고객, 투자자에게 어떤 영향을 미칠까요?
- 데이터 유출을 어떻게 방지할 수 있나요?
- 데이터 유출 후 노출을 줄이려면 어떻게 해야 할까요?

우리는 스타트업이 겪는 여러 단계에 따라 예상되는 보안 권장 사항을 그룹화했습니다. 스타트업이 취급하는 돈과 데이터가 많을수록 보안에 대한 투자도 커집니다:

1단계: 거실에서 일하기 (또는 직장에서 생활하기)

관리자 비밀번호 공유하기

모든 제품에는 적어도 한 명의 사용자, 관리자가 있습니다. 소규모 스타트업의 인원이 4명 정도라면 기본 관리자 비밀번호를 복잡한 비밀번호로 바꾸고 공유를 지원하는 비밀번호 관리자와 공유하는 것이 가장 좋습니다.
공유를 하는 이유는 한 직원만 시스템에 대한 권한을 가지고 있는데 다른 직원이 필요한 상황을 피하기 위해서입니다.
각 서비스마다 각기 다른 사용자를 두는 것이 바람직합니다. 관리자(특수한 상황), 개발자(일상적인 업무용), 서비스 사용자(코드용)를 만드는 것이 중간 지점입니다. 개발자가 퇴사하더라도 서비스 비밀번호를 교체할 필요가 없다는 것이 이 아이디어의 핵심입니다.
직원들에게 결국에는 노트북 비밀번호와 비밀번호 관리자의 비밀번호 두 가지를 외워야 한다고 설명하세요.
직원들에게 '집' 또는 '개인' 비밀번호를 사용하지 않도록 설명하세요. 이러한 비밀번호는 이미 노출되었거나 노출될 가능성이 높습니다. https://haveibeenpwned.com를 참조하세요.
비밀번호 관리자의 비밀번호를 선택하는 방법을 설명합니다. Sophos의 짧은 동영상에 설명이 나와 있습니다.

피싱 이메일, 포르노, 토렌트는 변장한 악마입니다

직원들은 아마도 집에서 업무용 노트북을 개인적인 용도로 사용할 것입니다. 괜찮습니다. 하지만 첫날부터 직원들에게 토렌트 다운로드나 포르노 또는 기타 수상한 웹사이트에 사용하지 말라고 설명하세요. 그런 용도로는 중고 노트북을 구입하도록 요청하세요.
해킹을 당했다면 직원이 피싱 이메일의 링크를 클릭하는 것부터 시작될 가능성이 높습니다. 재미있는 시작 활동 중 하나로 피싱 퀴즈를 플레이해 보세요.
이메일 첨부 파일 사용을 중단하세요. 이메일 첨부파일을 열어보는 데 익숙한 직원들이 실수로 멀웨어를 가장 먼저 설치합니다. 문서 공유는 Google 드라이브를 사용하거나 규제 환경에 있는 경우 박스를 사용하세요.
기타 내부 커뮤니케이션은 Slack을 사용하세요. 이메일은 고객 및 공급업체와 연락할 때 사용합니다.
비밀번호 관리자를 사용해 비밀번호, 자격 증명, 비밀 메모를 공유하세요.
USB 썸 드라이브 사용 중단: 이러한 불쾌한 장치를 컴퓨터에서 완전히 멀리하는 것을 회사 문화로 정착시키세요. 해커가 시스템을 장악하는 가장 빠른 방법이기 때문입니다. 직원들에게 이를 주요 위협으로 인식하고 식별하도록 교육하세요!
더 자세한 배경은 DBIR 보고서를 참조하세요.

오늘날에는 클릭 한 번으로 암호화가 가능합니다

노트북을 분실하거나 도난당했을 때 데이터가 손상되는 것을 원치 않으실 겁니다.

Mac 사용자는 클릭 한 번으로 드라이브를 암호화할 수 있습니다.
Windows 사용자는 Pro 버전이 필요하며 TPM을 지원하는 노트북 하드웨어를 선호합니다.
Linux 사용자는 디스크를 다시 포맷해야 합니다.

노트북 선택에 대한 참고 사항. 향후 규정 준수 요건(예: MDM)으로 인해 모든 노트북을 중앙에서 제어해야 하는 경우, 대부분의 공급업체가 Linux를 지원하지 않는다는 점을 알아두세요. Mac, Windows Pro, Android, iPhone - 예. Linux는 일반적으로 부분적으로 지원되거나 존재하지 않습니다.

탈옥하지 않은 아이폰은 안드로이드에 비해 해킹하기가 훨씬 더 어렵습니다. 또한 기본적으로 화면 잠금 및 암호화가 활성화되어 있습니다. 관리자와 관리자가 휴대폰에서 화면 잠금 기능을 사용하고 암호화를 사용 설정했는지 확인하세요.

알려진 취약점을 수정하세요

대부분의 운영 체제(노트북 또는 클라우드)에는 자동 보안 업그레이드 옵션이 있습니다. 대부분의 경우 단 한 줄의 설정이면 됩니다. 이렇게 하면 공격 표면을 약 10배 줄일 수 있습니다.

최소 2~3개의 도메인 네임을 구매하세요

웹사이트용 도메인, API용 도메인, 내부용 도메인이 하나 이상 필요합니다.

첫 번째 도메인은 일반적으로 회사의 공식 이름 또는 브랜드입니다. 이 도메인은 아웃바운드 마케팅(웹사이트)과 직원 이메일에 사용됩니다. 두 도메인 모두 외부 서비스 제공업체에서 관리할 수 있습니다. 이 이메일 도메인을 SPF와 DKIM으로 보호하세요. 그렇게 복잡하지 않으며 해커가 관리자나 관리자로 사칭하는 피싱 시도를 줄일 수 있습니다. 많은 보안 사고는 직원이 피싱 이메일을 여는 것에서 시작되므로 이 점이 중요합니다.
두 번째 도메인은 SaaS 서비스 자체(예: 나머지 API 엔드포인트)에 필요합니다. www.google.com 대 www.gmail.com 대 maps.googleapis.com 를 생각해보세요. 이 도메인은 회사 도메인과 달리 AWS Route53에서 호스팅되고 서비스 엔지니어링 팀에서 직접 관리하므로 각별한 주의가 필요합니다.
내부 사용 및 백오피스를 위해 세 번째 도메인이 필요합니다. 이 도메인은 즉시 알아볼 수 있어야 하며, 쉽고 빠르게 입력할 수 있어야 합니다. 일부 회사는 회사 도메인의 하위 도메인을 사용합니다. 그러나 이는 소규모 내부 서비스를 위해 자주 업데이트해야 하는 백오피스 서비스 개발자가 관리할 수 없다는 것을 의미합니다. 또한 하위 도메인은 어떤 사이트가 내부 사이트이고 어떤 사이트가 공개 사이트인지 혼동을 일으킬 수 있습니다. 이 도메인을 익명으로 등록하면 부수적인 이점도 있습니다. 대부분의 경우 DNS 서버도 내부에 있습니다. (비공개 Route53 도메인)
대량 이메일 발신자는 마케팅, 거래 및 회사 메일에 대해 별도의 도메인 또는 하위 도메인을 유지해야 합니다. 이렇게 하면 각 이메일 유형의 평판을 분리하고 시간에 민감한 거래 및 회사 메일이 지연되거나 스팸으로 표시되지 않도록 할 수 있습니다. 별도의 이메일 마케팅 도메인을 사용할 때는 Snowshoe 스팸이 아닌지 확인하고 고객이 회사 또는 서비스 웹사이트로 웹 전달을 사용하여 고객이 회사를 찾을 수 있도록 하세요.

어디서나 SSL/TLS/HTTPS를 사용하세요

가능한 모든 곳에서 SSL을 사용하세요. 웹사이트, API, 백오피스 서버, 그리고 내부 서비스 간에도 크게 어렵지 않다면 어디든 사용하세요.

보다 쉬운 자동화를 위해 AWS ACM 또는 Let's Encrypt ACME를 살펴보세요.

엔드포인트의 공인 인증서 만료일을 모니터링하여 인증서 만료 방지를 감지하세요.

SSL은 네트워크 트래픽을 암호화하지만 인증을 제공하지는 않는다는 점을 기억하세요. 또한 SSL은 2FA를 대체할 수 없습니다.

SaaS 공급업체 선택하기

한 번 인프라 공급업체에 맡기면 그 공급업체를 바꾸기가 어렵습니다. 앞으로는 조직의 데이터에 액세스할 수 있는 공급업체를 선별해야 합니다. 따라서 클라우드 인프라의 경우 대형 벤더(Amazon, Google, Microsoft) 중 하나를 선택하거나 최소한 SOC2 Type2 인증(인프라 벤더의 경우), 결제 벤더의 경우 PCI 또는 기타 해당 업계의 관련 인증 또는 규정 준수를 갖춘 벤더를 선택해 보세요.
그렇다고 해서 해당 업체의 서비스가 좋다는 의미는 아닙니다. 서비스가 좋더라도 나중에 교체할 필요가 없다는 뜻입니다.
기본적으로 AWS 사용자는 오레곤(us-west-2)을 선택합니다. 목표 시장이 어디에 있는지 알고 있다면 목표 시장에 가까운 데이터 센터부터 시작해야 합니다.
데이터 센터가 위치한 국가(데이터 레지던시)의 규제 관련 사항도 있습니다. 유럽 고객의 경우 이는 거래를 방해하는 요인이 될 수 있으며, 나중에 다른 지역으로 이전하는 데 막대한 비용이 발생할 수 있습니다.

API 관리

회사에서 API를 서비스 형태로 노출하는 경우 각 고객에게 고유한 액세스 자격 증명이 있는지 확인하세요. 그렇지 않으면 고객의 QA 중 한 명이 테스트 스크립트에 버그를 발견할 때 서비스가 중단될 수 있습니다.

직접 롤링하는 대신 API 관리 솔루션을 사용하는 것을 고려하세요. 이러한 솔루션은 토큰 해지 및 표준 프로토콜과의 통합을 포함하여 브라우저 to 서버, 모바일 to 서버, 서버 to 서버 인증 토큰 지원을 제공합니다.

Git으로 일하기

Git과 풀 리퀘스트 방식은 버전 관리를 수행하는 사실상의 표준 방법입니다. 규정 준수 요구 사항의 일부로 스타트업이 적절한 버전 관리 제어 및 테스트를 수행하고 있음을 입증해야 합니다. 지금 시작하는 것이 좋습니다.

Git을 사용하면 커밋 권한을 부여했다가 취소하는 방식으로 한시적으로 아웃소싱/프리랜서 개발자를 추가할 수 있습니다.

2단계: 첫 번째 고객과 계약하기 / 시리즈 A

약간 편집증적일 수 있습니다.

사용하는 모든 서비스에 대해 2FA를 사용 설정하세요. 이러한 서비스는 유출될 경우 제품을 오프라인 상태로 만들 수 있는 서비스이므로 개발팀에게 특히 중요합니다. Google 계정, Dropbox, Github, Microsoft 등 모든 서비스가 해당됩니다
기업 고객을 대상으로 하거나 규제 환경에서 일하는 스타트업은 보통 첫날부터 2FA를 활성화합니다.
잘 확립되어 있고 사용하기 쉬운 2FA 구현은 TOTP 2FA 구현입니다. 직원은 휴대폰에 Google 인증기를 설치하면 비밀번호와 함께 입력해야 하는 일회성 6자리 코드를 생성할 수 있습니다.
조금 더 유용한 접근 방식은 푸시 알림입니다. 많은 SaaS 공급업체가 코드를 생성하는 대신 푸시 알림을 보내는 앱을 지원합니다. 로그인할 때마다 6자리 숫자를 복사하는 것보다 훨씬 편리합니다. 단점은 각 서비스마다 다른 앱이 필요할 수 있으며 인터넷에 연결되지 않거나 푸시 알림 공급업체가 다운타임이 있는 경우 작동하지 않는다는 것입니다.
휴대폰 2FA 문제는 직원이 휴대폰을 분실/분실/교체하거나 배터리가 부족하여 시스템에서 잠기는 경우 시작됩니다. 일부 직원은 휴대폰을 강화하는 것(2FA 앱을 보호하기 위한 암호화 및 화면 잠금)을 싫어하고 2FA 앱을 실행하기 위해 회사에서 휴대폰을 구입해야 한다고 생각합니다. 그래서 일부 조직에서는 Yubikey(사람의 손가락 터치를 감지할 수 있는 작은 USB 플러그)를 대신 사용합니다. 모바일 앱 푸시 알림과 마찬가지로, 유비키는 비밀번호를 키로깅하는 멀웨어와 해커로부터 보호합니다. 단점은 휴대폰과 달리 직원들이 노트북과 함께 유비키를 분실할 가능성이 높다는 것입니다. 따라서 도난당한 노트북이 노트북에서 비밀번호를 추출할 수 있는 전문가의 손에 넘어가면 유비키를 사용하여 모든 서비스에 로그인할 수도 있습니다. 또 다른 문제는 유비키가 USB 장치이기 때문에 USB 저장 장치(허용되지 않음)와 유비키(허용됨)를 구분해야 한다는 것입니다.
2단계 인증에 SMS를 사용하는 것은 권장하지 않으며 비활성화해야 합니다. 숙련된 해커는 모바일 네트워크 고객 지원팀에 자신의 소유로 회선을 옮기도록 설득할 수 있습니다. 또한 최근에는 8억 대의 안드로이드 디바이스에 SMS를 읽는 멀웨어가 있는 것으로 밝혀졌습니다.
2단계 인증에 음성 전화 사용도 비활성화해야 합니다. 해커는 휴대폰이 오프라인 상태일 때 로그인을 시도하고 사용자가 변경한 적이 없는 4자리 코드를 추측하여 음성 사서함을 해킹할 수 있습니다. (변경하세요)
직원이 원격으로 비밀번호 재설정을 요청하는 경우 가능하면 직접 사무실로 오도록 요청하세요. 이것이 불가능하거나 시간이 촉박한 경우에는 직원의 목소리를 인식할 수 있다고 믿지 말고 신원을 확인합니다. 비밀번호는 절대로 이메일로 보내지 마세요.

조직에서 정보를 훔치는 내부자

퇴사/해고 직원을 위한 체크아웃 양식을 준비합니다. 프로비저닝 해제/중지가 필요한 모든 서비스의 목록을 작성하세요. (Whatsapp 그룹도 기억하고, 이 과정에서 Whatsapp을 통해 도어 비밀번호를 보내지 마세요)
해고된 직원이 민감한 정보를 다운로드했는지 Google 문서 도구 로그(또는 이와 유사한 로그)를 확인하세요.
대부분의 엔드포인트 보안 제품은 노트북에서 데이터를 복사하기 위한 장치(예: USB, Bluetooth, 모바일)의 사용을 차단하도록 구성할 수도 있습니다.
해고된 직원이 관리자 비밀번호에 액세스할 수 있는 경우, 민감한 시스템의 비밀번호를 교체하는 것이 좋습니다.
신입 직원을 채용할 때는 해당 직원의 이전 직장 동료에게 성격 유형과 이전 회사를 떠난 방식에 대해 물어보세요. 적어도 이스라엘에서는 직원에게 범죄 기록지를 제시하도록 요구하는 것은 불법이라는 점에 유의하세요.

VPN

사무실 VPN을 설치할 수 있는 통합 공급업체는 비교적 쉽게 찾을 수 있습니다. (직접 설치하지 마세요)
사무실에 배포된 VPN과 사무실 인터넷용 고정 IP 주소를 조합하여 서버에 대한 관리 액세스를 제한할 수 있습니다. 예를 들어, 22번 포트(SSH)를 전체 인터넷에 개방하는 대신 사무실 또는 사무실의 VPN에 연결된 집에서의 액세스만 허용할 수 있습니다.
또는 클라우드 기반 VPN(예: EC2에 설치)에는 몇 가지 장점이 더 있습니다. 첫째, 사무실과 클라우드 간의 모든 통신이 암호화됩니다. (SSL 없이 탄력적 검색과 같은 데이터 저장소에 액세스하는 경우 특히 중요합니다) 네트워크 성능은 물리적으로 사무실과 멀리 떨어져 있는 원격 근무자에게 훨씬 더 좋습니다. 또한 네트워크 장비가 없기 때문에 물리적 보안의 필요성이 다소 완화됩니다. (사무실은 커피숍에 불과합니다) 단점은 사무실 네트워크 연결이 끊어질 때마다 VPN에 다시 연결해야 한다는 것입니다.
VPN 연결도 2FA를 사용해야 합니다.

안티바이러스/방화벽

엔드포인트 보안 제품을 설치하는 것은 매우 쉽습니다. 제품이 모든 노트북의 운영 체제를 지원하는지 확인하세요. 자동 업데이트를 구성하고, 이메일 알림을 보내고(시끄러울 수 있음), 들어오는 모든 연결을 차단하세요. 마지막 항목은 로컬에서 서버를 실행하는 개발자에게 중요합니다.
바이러스 백신을 설치하면 거부하는 개발자가 많기 때문에 직원이 입사하기 전에 바이러스 백신을 설치하는 것이 좋습니다.
대부분의 제품에는 내보내기/가져오기 기능이 있어 쉽게 설정할 수 있습니다.
바이러스 백신에 EDR이라는 추가 보호 제품(예: Cybereason, Black Cobalt)이 있지만 일반적으로 비용이 많이 듭니다.

적절한 비밀번호 해시 기능으로 고객의 비밀번호를 해시하세요.

여유가 있다면 비밀번호 저장, 비밀번호 관리, 비밀번호 복구, 2단계 인증 등을 처리할 수 있는 타사 인증 서비스를 이용하세요. 일부 공급업체는 예산에 맞는 월별 활성 사용자 요금제를 제공합니다.

그러나 자체 인증 구현을 개발하기로 결정한 경우 OWASP 인증 가이드라인 을 따르세요.

데이터베이스가 유출되어 공개된 경우 고객의 비밀번호가 포함되어 있고 사람들이 비밀번호를 재사용하는 등 쉽게 해독할 수 있다면 훨씬 더 심각한 문제입니다. 사실입니다. 따라서 데이터베이스에 고객 비밀번호를 저장할 때는 항상 비밀번호 저장용으로 특별히 설계된 해싱 함수(bcrypt, PBKDF2 또는 비밀번호 해시에 약 1초가 소요되는 scrypt)를 사용하세요. MD5, SHA1 또는 비밀번호 용으로 특별히 설계되지 않은 기타 해시 함수는 사용하지 마세요. 이렇게 저장된 비밀번호는 보통 몇 초 안에 해독됩니다.

물리적 보안

노트북을 책상에서 최대 5분간 자리를 비우면 절전 모드로 전환하고 다시 열려면 비밀번호를 입력하도록 설정하세요. 직원들이 책상을 떠날 때 macOS의 경우 핫 코너를 사용하거나 Windows의 경우 로고 키 + L을 눌러 노트북을 수동으로 잠그도록 요청하세요.
낯선 사람이 컴퓨터에 접근하지 못하도록 하세요.(특히 USB 포트가 있는 경우) 물리적인 접근은 시스템과 제품, 고객을 침해하는 가장 빠른 방법입니다.
직원들에게 집에 가기 전에 모든 문과 창문을 잠그고 알람을 활성화하도록 상기시키세요.
근무 시간 동안 현관문에 코드를 추가하여 사무실 도난을 방지하세요. 직원들에게 다른 직원과 함께 있지 않은 낯선 사람이 사무실에 들어올 경우 먼저 다가가도록 요청하세요.
서버실(또는 네트워크 장비가 있는 방)을 잠그세요.

클라우드 서버가 손상되지 않도록 하기

클라우드 방화벽 구성을 검토하여 당황스러운 실수가 없는지 확인하세요.
이메일 그룹을 열어 [email protected]라는 이름을 지정하고 웹사이트에 이 이메일로 보안 사고를 신고할 수 있는 페이지를 추가합니다. 보안 조사에서는 암호화된 이메일 전송을 선호할 수 있으므로 OpenPGP 키 쌍 생성을 통해 공개 키를 웹사이트에 게시하고 비공개 키를 비밀번호 관리자에 저장해야 합니다.
여러분을 제외한 모든 사람이 알고 있는 심각한 알려진 취약점이 있을 때 알림을 받으려면 Zapier 계정을 개설하고 클릭 몇 번으로 취약점 RSS 피드를 Pagerduty에 연결하세요. 다음은 RSS 피드와 샘플 Zapier 필터 구성입니다.
https://nvd.nist.gov/download/nvd-rss.xml
나중에 프로덕션 네트워크와 개발 네트워크를 분리하는 것은 매우 어렵습니다. AWS에서는 계정 수준에서 보안을 가장 쉽게 관리할 수 있으므로 개발 VPC는 동일한 조직에서 별도의 계정에 있어야 합니다. 일반적으로 세 개의 계정이 있습니다. 하나는 통합 청구용, 하나는 프로덕션용, 다른 하나는 기타 모든 계정(네트워크 ACL을 통해 사무실과만 통신하도록 구성된 개발 및 백 오피스용)입니다.
최근 Amazon은 한 단계 더 나아가 모든 다른 계정에 정책을 쉽게 적용하고 청구도 처리할 수 있는 AWS Organizations를 발표했습니다.
프로덕션과 개발을 분리하는 것의 단점은 경우에 따라 프로덕션에서 개발로(또는 그 반대로) 데이터를 복사하려는 경우 VPC 피어링과 사용자 지정 ACL 규칙이 필요하다는 것입니다. 로켓 과학은 아니지만 주의가 필요합니다.

3단계: 대중 시장 또는 기업 고객

인증 및 규정 준수

대규모 고객을 대상으로 판매를 시작하면 보안과 관련된 규정 준수 요구 사항 및 인증에 대해 다시 보고하게 됩니다. 우선 당황하지 마세요. 다음으로, 회의와 문서를 처리할 수 있고 충분한 기술력을 갖춘 직원을 찾으세요.
면제를 받을 수 있는 섹션을 파악하고 인증 범위를 제한하세요. 다음은 몇 가지 예입니다:
- 다른 Amazon 계정을 개설하고 직원 2명만 액세스할 수 있는 몇 가지 서비스를 이동해야 하는 경우에도 노력할 가치가 있습니다. 해당 계정과 두 명의 직원으로만 인증을 제한할 수 있습니다.
- 프로덕션 서비스(고객에게 서비스를 제공하는)와 백오피스 서비스(직원에게 서비스를 제공하는)를 다른 계정으로 분리하는 것을 고려하세요. 일반적으로 프로덕션 계정이 더 엄격하게 규제됩니다.
- 무엇보다도 모의 침투 테스트를 수행해야 합니다.
보상 컨트롤이라는 중요한 개념이 있습니다. 이것은 특정 요점을 강제할 수 없을 때 (드물게) 사용할 수 있는 에이스 카드입니다. 예를 들어, 정책 위반이 있을 때 매니저에게 메시지를 보내는 슬랙 봇은 이 정책이 시행되지 않는 것에 대한 보상 제어입니다. 소규모 조직에서는 일반적으로 정책을 강제하기보다는 드물게 발생하는 사례에 대해 경고하는 것이 더 합리적입니다.
인증의 큰 부분은 회사의 다양한 부분에 대한 프로세스와 프로세스 문서화에 관한 것입니다. 소규모 스타트업의 경우 언제 Git을 사용하는지, 언제 구글 문서를 사용하는지, 마지막으로 퇴근할 때 어떤 문을 잠그는지 등을 설명하는 구글 문서를 작성하세요. 신입 사원의 첫 날 읽기 자료로 작성하고 최신 상태로 유지하세요. 이렇게 하면 유용할 뿐만 아니라 여러 자격증 취득에도 도움이 될 것입니다. 일부 문장에 요구 사항 1.2.3을 참조하여 주석을 달면 더 쉽게 찾아볼 수 있습니다.
규정 준수/인증 비용 자체와 총 비용(침투 테스트, 인건비, 판매 주기에 맞춰 완료하기 위해 프리랜서의 도움이 필요할 수 있음)을 주시하세요.

개발자를 참여시키세요 - 개발자는 중요한 역할을 합니다.

개발자는 권한을 빼앗기면 매우 개인적으로 받아들이고 심지어 화를 낼 수도 있습니다. 관리자 권한을 유지하는 다른 개발자들과 비교하여 자신들이 더 이상 신뢰받지 못한다고 느낄 수 있습니다. 인증을 주도한 사람이 자신을 희생하면서 자존심 싸움을 하고 있다고 느낄 수도 있습니다. 다른 사람들은 수갑을 차고 수렁에 갇혀서 '기업'을 위해 일하기 시작했다고 느낄 수도 있습니다.
모든 사람을 의사 결정에 참여시킬 수는 없지만, 다양한 의견을 가진 대표자를 포함시키기 위해 부끄러워하지 않고 발언할 수 있도록 노력할 수는 있습니다. 개발자는 일반적으로 "징징거리는" 사람이 아니라 누가 그런 것들을 필요로 하는지 이해하지 못하는 사람입니다. 따라서 어떤 부분이 인증에 중요한지, 어떤 부분이 인증 과정에서 추가되고 있는 백로그 항목인지 계속 지적하는 것이 중요합니다. 보안 요구 사항에 매핑된 구체적인 고객 이름을 지정하세요.
자동화에 필요한 시간을 고려하세요. 최근까지 상승된 권한이 필요했던 일반적인 작업에는 자동화를 사용해야 합니다. 예를 들어, 새 고객을 추가하거나 새 버전으로 업그레이드하는 작업이 이에 해당합니다. 자동화를 사용하지 않으면 모든 사람에게 관리자 권한이 필요하지만, 적절한 자동화(예: Jenkins 작업)를 사용하면 모든 직원이 스스로 해당 작업을 수행할 수 있습니다. 절차를 변경하려면 당연히 동료 검토(풀 리퀘스트)가 필요합니다.
팀 리더와 관리자에게 관리자 권한을 사용하지 않도록 상기시키고, 다른 사람들과 마찬가지로 일상적인 업무에는 자동화를 사용하도록 하세요. 관리자 권한은 다른 사람을 질투하게 만드는 데 사용해서는 안 되며, 자동화가 처리하지 못하는 롱테일 작업을 위한 외과적 조치에 사용해야 합니다. 이는 모범과 예의의 문제입니다.
특정 직원에게 특정 컴포넌트에 대한 관리자 권한을 제한된 시간 동안 제공하는 프로세스를 정의하세요. 개발자가 새 컴포넌트의 개발 속도를 높이거나 반복적인 작업을 자동화하기 위해 이틀 동안 관리자 권한이 필요한 경우가 있습니다. 감사자에게 제시할 수 있는 로깅 추적이 있는 프로세스를 정의하세요. 이는 개발자가 하루에 열 번씩 관리자에게 갈 필요가 없도록 하기 위해 필요한 것으로, 관련된 모든 당사자에게 많은 불만을 야기할 수 있기 때문입니다.
일부 (소규모) 회사에서는 모든 개발자가 관리자라고 정의하기도 합니다. 감사자가 이를 인정하고 보고서에 이에 대한 코멘트를 추가할 수도 있습니다.
보안과 사용자 경험의 균형을 유지하여 마찰을 줄이세요. 개발자가 관심을 갖지 않고 규칙이 자신에게 적용되지 않는다고 믿는 것은 가장 바람직하지 않습니다. 보안 피로의 징후를 살펴보고 문제를 신속하게 해결하세요.

프로덕션에 영향을 미치는 모든 변경 사항에 대해 변경 관리 사용

이 시점에서는 이미 자동화된 테스트와 프로덕션 배포와 롤백이 (최소한 반쯤) 자동화되어 있어야 합니다. 다음 단계는 프로덕션 시스템이 불변인지 확인하는 것입니다. 즉, 한 번 배포된 서버는 절대 수정되지 않고 업데이트된 새 인스턴스로 교체될 뿐입니다.

단점은 자동화 서버가 다운되거나 몇 가지 테스트가 산발적으로 실패하면 조직이 중단된다는 것입니다. 긴급한 퀵픽스를 프로덕션에 배포해야 할 때 늘 머피의 법칙이 작동하고 바로 이런 상황이 발생할 수 있습니다.
다음은 이 자동화를 재정의할 수 있는 방법이 필요하다는 것입니다. 관리자 권한일 필요는 없습니다. 테스트되지 않은 아티팩트를 프로덕션에 푸시하는 것을 의미하는 태그가 될 수도 있습니다. 개발자가 이 태그를 보상 제어로 사용하면 관리자/관리자에게 알림을 보낼 수 있습니다.
프로덕션 동작에 영향을 미치는 데이터베이스 값 또는 토글의 변경은 반드시 변경 관리(풀 리퀘스트 또는 이와 유사한 시스템)를 거쳐야 합니다.

ID 관리 및 SSO

특정 시점에 이르면 SaaS 공급업체의 수가 직원 수보다 많아져 비밀번호 관리자가 관리하기 어려워지며, 특히 직원이 조직에 입사하거나 퇴사할 때 더욱 그러합니다. 비밀번호는 관리자만 사용할 수 있으며, 다른 모든 SaaS 애플리케이션은 동일한 ID 관리 서비스(통합 인증 지원)를 사용해야 합니다.
이러한 플랫폼을 통합하는 데는 다소 시간이 걸립니다. 우선, Google G-Suite는 OAuth 또는 SAML을 지원하는 모든 사이트에 대해 SSO를 수행할 수 있습니다. 또한 브라우저 기반 인증, 직원과의 마찰을 줄이기 위한 스마트 2FA 규칙, ldap 또는 radius를 통한 VPN/SSH와의 통합을 지원합니다.
일부 공급업체는 관리자 권한 관리 서비스를 제공하지 않습니다. 따라서 관리자는 여전히 비밀번호 관리자를 사용해야 합니다.

물리적 보안

사무실 건물 보안과 보험 회사에서는 업무 외 시간에도 알람을 활성화할 것을 요구할 수 있습니다. 23:00에 자동으로 활성화하는 것이 좋으므로 직원 중 한 명이 잊어버린 경우 수동으로 활성화할 필요가 없습니다.
사무실 입구가 보안 카메라로 모니터링되지 않는다면 모바일 앱에 연결되는 간단한 인터넷 카메라를 구입할 수 있습니다. 따라서 누가 마지막으로 퇴근하고 문을 잠그거나 알람을 작동시키는 것을 잊었는지 모니터링할 수 있습니다. 그리고 실제 도둑이라면 얼굴을 볼 수 있습니다.
이 시점에서 현관문 핀 코드를 칩 기반 도어 시스템으로 교체할 수 있습니다.
그 이유는 직원이 퇴사할 때마다 코드를 교체할 필요가 없기 때문입니다. 청소 서비스는 며칠 내에 직원을 교체할 수 있으므로 칩을 받지 못할 수도 있다는 점을 고려하세요. 따라서 퇴근 후 문을 잠글 수 있는 사람을 두어야 합니다. 마그네틱 도어 카드(마그네틱 스트라이프와 머그샷이 있는)는 일반적으로 더 비싸고 신입 직원과 지원자에게 더 회사스러운 냄새를 풍깁니다. 그러나 도어 칩 시스템에 비해 복제하거나 해킹하기가 더 어렵습니다.

4단계: 대규모 고객 계약 또는 급격한 시장 성장

고객 사용자 관리

로그인 및 고객의 비밀번호 관리 서비스를 제공하는 서비스형 인증업체는 여러 곳이 있습니다. 이러한 공급업체가 SOC2 규정을 준수하는 경우 고객의 비밀번호를 데이터베이스에 저장하는 것보다 더 나은 서비스를 제공할 수 있습니다.

또한 사용자 프로비저닝 및 프로비저닝 해제, 비밀번호 정책 적용, 분실된 비밀번호 복구를 위한 셀프 서비스 및 API를 제공합니다. 하지만 대규모 고객은 자체 ID 관리 솔루션과의 통합을 원할 수도 있습니다.

민감한 데이터 유출

데이터 유출로 인한 재정적 영향(비즈니스 손실 및 보상)은 스타트업을 파산에 이르게 할 수 있습니다.

보안 교육의 일환으로 직원들에게 개인 정보의 구성 요소와 조직에서 이를 어떻게 처리하는지 설명하세요.
- 개인정보 보호의 미래 포럼에서 시각적 가이드를 게시하여 시작하는 데 도움이 될 수 있습니다.
직원들에게 실수를 했다고 해서 해고하지 않을 것이라고 설명하세요. 사고 발생 시 최대한 빨리 알려주어 문제를 해결하고 피해를 최소화할 수 있도록 해달라고 부탁하세요. 이 약속을 지키세요. 의도적인 내부자의 데이터 유출과 불행한 인적 오류의 차이점을 설명하세요. 직원마다 문화적 배경과 업무 배경이 다르고 잘못된 방식으로 반응할 수 있으므로 이에 대해 이야기해야 합니다.
데이터를 미리 삭제하거나 비식별화하여 데이터 유출로 인한 잠재적 피해를 줄이세요. 이를 위해서는 일반적으로 현재 필요하다고 간주되는 데이터가 없더라도 조직이 생존할 수 있다는 비즈니스 결정을 내려야 합니다. 민감한 데이터를 미리 제거하거나 최소한 대부분의 직원에게 해당 데이터에 대한 액세스를 거부함으로써 기업 냄새가 나는 보안 소프트웨어의 필요성을 연기하는 것입니다.
적절한 장소에서 적절한 도구를 사용하여 데이터 유출을 방지하세요:
- 로컬 데스크톱 대신 원격 가상 데스크톱에서 작업하여 데이터를 노트북에서 멀리 이동합니다.
- 브라우저 격리 기술을 사용하여 멀웨어를 노트북에서 멀리 이동시킵니다. 이렇게 하면 일반 브라우저에서 로컬로 검색하는 것 같은 느낌을 주지만 실제로는 원격 컴퓨터에서 검색을 수행하는 픽셀만 표시됩니다.
- 휴대폰과 노트북에서 데이터 유출 방지 에이전트를 사용하여 데이터 유출을 모니터링하고 방지합니다. 이를 위해서는 모든 조직 자산에 배포하고 특정 데이터 유형에 대한 구성 및 모니터링이 필요합니다.
- 모바일 기기 관리 에이전트를 사용하여 노트북 및 모바일 애플리케이션 프로비저닝과 운영 체제 설정(화면 잠금/암호화/VPN 설정 등)을 모니터링하거나 관리할 수 있습니다. Google G-Suite에는 기본 MDM 기능이 내장되어 있습니다.
- 인증 및 권한 부여로 모든 데이터 저장소를 보호하세요. 포렌식 조사 및 데이터 모니터링을 위해 관련 트랜잭션을 감사하세요.
- 데이터 저장소 읽기/쓰기 작업(인덱싱이 필요하지 않은 경우)에는 앱 수준 암호화를, 데이터 저장소에는 디스크 및 네트워크 수준 암호화를 사용하세요.

인터넷 대면 서비스 해킹 방지

OWASP 상위 10가지를 기반으로 보안 코드 교육을 실시합니다.
WAF 및 DDoS 완화 서비스를 사용합니다.
외부 취약점 스캔(네트워크 외부)을 실행합니다. 이렇게 하면 쉬운 공격 대상을 찾는 키디 스크립트로부터 사용자를 보호할 수 있습니다.
내부 취약성 스캔(방화벽 내부)을 실행합니다. 이렇게 하면 한 서버에서 발판을 마련한 해커가 시스템의 핵심으로 측면 이동을 시도하는 것을 방지할 수 있습니다. 이를 위해서는 일반적으로 에이전트 또는 SSH 액세스 권한이 필요하며 방화벽 없이 스캔할 수 있어야 합니다.
모의 침투 테스트 및 버그 바운티 프로그램을 활용하세요. 실제 해커에게 돈을 지불하고 특정 취약점을 찾아내는 방법입니다. 이 테스트를 하는 동안 외부 모의 침투 테스트 공급업체가 보안을 우회하고 취약점 및 잘못된 구성을 이용하도록 허용하는 것입니다.
- 고객 중 한 명이 해킹을 당한 상황을 시뮬레이션하기 위해 펜 테스터 API 키를 제공하고 해커가 비밀 API 키를 사용하여 조직에 침투하는 경우도 있습니다. 이를 그레이 모의 침투 테스트라고 합니다.
- 다른 경우에는 모의 침투 테스트가 코드베이스를 검토하도록 허용할 수도 있습니다. 가격은 서비스의 복잡성, 해커의 경험, 코드 라인에 따라 달라집니다.
- 바운티 프로그램을 사용하면 특정 기술을 가진 해커를 찾을 수 있습니다.
라이브러리 종속성을 정기적으로 업그레이드하세요. 또는 라이브러리 버전을 업그레이드하기 위해 풀 리퀘스트를 자동으로 생성하는 봇을 사용하는 것이 더 좋습니다.
소스 코드 취약점을 스캔하세요. 여기에는 다음이 포함됩니다:
- 알려진 취약점(및 라이선스 문제)에 대한 종속성 모니터링(Snyk, SourceClear, BlackDuck과 같은 서비스)
- 코드의 정적 및 동적 코드 분석(CheckMarx, Veracode)

데이터 백업

백업에서 복원하는 데 시간이 걸리더라도 조직의 중요한 데이터가 백업되어 있는지 확인하세요:

데이터 누락으로 인한 공백을 방지하기 위해 백업이 자동적이고 지속적으로 이루어지며 필요한 데이터 세트를 포함하는지 확인하세요.
사람의 실수나 악의적인 데이터 삭제를 방지하기 위해 백업이 다른 클라우드 계정에 있는지 확인하세요.
자연재해로 인한 데이터 손실을 방지하기 위해 백업이 다른 지역의 다른 데이터 센터에 있는지 확인하세요.
일부는 데이터를 다른 클라우드 제공업체에 복사하기도 합니다. 예를 들어, Google Cloud에는 Amazon S3에 저장된 데이터를 지속적으로 백업할 수 있는 서비스가 있습니다.
모든 데이터가 비즈니스 생존에 똑같이 중요한 것은 아닙니다. 데이터의 양과 백업 비용이 너무 많다면 중요한 데이터부터 시작하세요.
복원 절차가 잘 문서화되어 있고 테스트를 거쳤는지 확인하세요. 유용한 백업이라고 생각했던 것이 데이터 손실로 인해 복구하려고 할 때 사용할 수 없다는 사실을 발견하고 싶지 않을 것입니다.
거의 모든 인증 기관이나 대형 고객은 연간 백업/복원 사례의 사본을 요청할 것입니다.

데이터 유출/해킹 사고 다음 날 아침을 대비하세요

비용이 조금 더 들더라도 가능한 모든 클라우드 서비스에 대해 로그를 사용 설정하세요. 모든 애플리케이션과 서버 인프라의 로그를 중앙 집중화하세요. 로그를 최소 1년 동안 저장하세요.
법률 고문(법률 사무소) 및 회계법인과 협력하여 사고 대응 계획을 준비하세요. 이는 발생한 피해를 조사, 수정 및 통제하기 위해 수행해야 하는 조치 목록입니다. 여기에는 고객, 최종 사용자 및 당국과의 커뮤니케이션도 포함됩니다. 대형 로펌 및 회계법인은 이러한 계획을 수립하는 데 도움을 줄 수 있는 인맥과 경험을 보유하고 있습니다.

5단계: "엄마, 나 신문에 나왔어!"

명확한 비즈니스 요구(큰 비즈니스 성공)와 적절한 보안 예산이 있다면 조직에 적합한 보안 책임자(또는 보안 부사장 또는 CISO)를 찾기 시작하세요. 이 과정은 수개월이 걸릴 수 있습니다. 그 이유는 첫 단계에 필요한 높은 기술력이 요구되고, 영업 주기에 참여하고 회사의 공식 서류에 서명하는 등 다른 특성이 필요한 CEO/CTO로부터 책임을 맡아야 하기 때문입니다. 물론 보안 책임자는 조직의 문화에 잘 맞아야 합니다. 이러한 인물의 실제 사례는 다음 동영상에서 확인할 수 있습니다: https://www.infoq.com/presentations/security-etsy

예산 결정 - 위협 모델 구축

위협 모델은 특정 보안 대책에 대한 투자가 정당한지 판단하는 데 사용할 수 있는 경험 법칙입니다. 모사드인지 아닌지는 두 가지 유형의 공격자를 고려하는 기본 위협 모델입니다: 국가 행위자와 그 외 모든 사람.

모사드의 공격을 받았다면 포기하세요. 모사드는 새 노트북을 도중에 하드웨어를 개조하여 교체하거나, 사무실에 몰래 침입하거나, 원격 탈옥 해킹 도구를 구입하거나, 심지어 직원 중 한 명을 갈취할 수도 있습니다. 이러한 위협을 막기 위한 투자는 돈 낭비입니다.

하지만 모사드가 아닌 자의 공격을 받는다면 합리적인 투자를 통해 효과적으로 자신을 보호할 수 있습니다. 투자 대상이 아닌 모사드에서 모사드가 된 시점을 판단하는 좋은 기준은 권한 있는 액세스 권한을 가진 직원에게 뇌물을 주는 등 차단하기 어렵고 매우 불법적인 공격 가능성을 고려하는 것입니다. 즉, 비밀번호를 해킹하는 데 드는 비용(즉, 무차별 암호 대입)이 액세스 권한을 가진 직원에게 뇌물을 주는 데 드는 비용보다 높다면 비밀번호를 보호하기 위해 더 많은 리소스를 투자할 필요가 없다는 뜻입니다.

예산 결정 - 다양한 고려 사항

회사가 성장함에 따라 공격 표면과 공격 동기 또한 증가한다는 점을 기억하세요. 시간이 지남에 따라 보안 예산도 그에 따라 증가해야 합니다. 이 예산은 투자자에게 보안을 중요하게 생각한다는 것을 보여줄 수 있습니다.
전체 위험 분석을 살펴보고 큰 구멍을 먼저 막아야 합니다. 가장 가능성이 높거나 가장 피해가 큰(또는 두 가지가 복합된) 위험부터 해결하세요. 하나의 공격 벡터에 모든 노력을 집중하면 공격자는 다음 구멍으로 이동하기만 하면 됩니다.
일부 요구 사항은 고객과 규정 준수에서 비롯되며 반드시 위험의 최상위에 있는 것은 아닙니다. 예를 들어, 아마존이 비즈니스 데이터를 복사하는 것을 두려워하는 고객은 AWS 내부에서 엔드투엔드 암호화된 트래픽을 요구할 수 있습니다. AWS 내부자가 데이터를 훔치거나 정교한 멀웨어가 가상 머신 격리를 뚫고 침입할 가능성이 있지만, 이는 귀사의 목록에서는 최우선 순위가 아닐 수 있지만 고객의 목록에서는 최우선 순위가 될 수 있습니다.

위험 관리

새로운 보안 관리자가 해야 할 첫 번째 단계 중 하나는 다양한 위험과 그 발현 가능성을 평가하는 것입니다.

높은 수준의 출발점을 위해 DBIR 보고서에서 제공하는 관련 통계를 살펴볼 수 있습니다:

DBIR 보고서를 기반으로 한 더 자세한 목록은 효과적인 사이버 방어를 위한 CIS 통제 문서의 부록 B와 C를 참조하세요.

다음 단계는 잠재적인 비즈니스 피해에 대한 정보에 입각한 추측을 하는 것입니다. 다음은 예시입니다:

공격	공격 벡터/행위자	올해 예상 공격 횟수	공격 피해(W, 기존 완화 조치)	올해 총 피해액
사기	CC 사기, 친근한 사기, 마켓플레이스 사기	높음	낮음	높음
다운타임	날씨, DDoS	중간	중간	중간
물건 절도	오피스 도둑, 자동차 도둑, 집 도둑, 내부자 오용	중간	낮음	낮음
IP 도용/유출	노트북 멀웨어, 모바일 멀웨어, 서버 취약점, 공급업체 해킹	낮음	높음	중간
(고객) 데이터 도난/유출	노트북 멀웨어, 모바일 멀웨어, 서버 취약점, 공급업체 해킹, 데이터 저장소 유출	중간	높음	높음
비즈니스/HR/내부 문서 도난/유출	노트북 멀웨어, Mobile, 공급업체 해킹	중간	중간	중간
파괴된 데이터 또는 몸값	서버 취약점, 자격 증명 도용, 노트북 멀웨어	중간	중간	중간
금전 손실(비트코인, ec2 인스턴스)	자격증명 도용, 서버 취약성	중간	중간	중간
서비스를 통해 해킹당한 고객	서버 취약성, 자격 증명 도용	중간	높음	높음

다음 단계에서는 각 위협에 대한 예방 및 노출 감소 기술을 자세히 설명합니다. 이 표는 작업 계획의 기초가 됩니다:

예방	노출 감소	공격 벡터/행위자
자동 사기 방지	DIY 휴리스틱 + 수동 검토	마켓플레이스 사기, 친근한 사기, CC 사기
다중 지역(활성 활성)	장애 조치 지역 연습	날씨
DDoS 보호	AWS 계정 관리자와 상담, 404/403 알림	DDoS
알람, 도어 칩, 2FA(휴대폰)와 노트북 분리, 잠금	모든 서버와 VPN을 클라우드로 이동합니다, 디스크 암호화, 노트북을 차에 두고 내리지 마세요, 핀 코드/암호, 원격 삭제(회사 휴대폰)	사무실 도난, 자동차 도난, 주택 도난
권한 있는 액세스 관리, DLP	직원 친절하게 대하기, 액세스 로그, MDM, 오프보딩 체크리스트, 개인정보 보호 교육, 신규 채용 참조 확인, NDA	직원 오용, 프리랜서 오용, 공급업체 오용
기업 데이터 볼트로 IP 이동, 엔드포인트 보호, DLP	최소 권한, 액세스 로그, 교육, 암호화된 데이터	멀웨어
OS/Docker 자동 업그레이드, 라이브러리 업그레이드, 외부 취약점 스캔, 침투 테스트, 보안 버그 바운티	취약점 RSS 피드, 로그인 실패 알림, 다른 클라우드 계정/지역에 백업, 네트워크 격리(보안 그룹/서브넷/VPN/클라우드 계정), 내부 취약성 검사	서버 취약성
2FA, 노트북의 보안 자격 증명, 서버의 자격 증명 보안	매년 관리자 비밀번호 교체	자격증명 도용
사용자 이름/비밀번호로 SQL/NoSQL 보호, 액세스하려면 VPN 2FA 필요, 앱 수준 암호화	사용되지 않는 데이터의 비식별화/수정/삭제, 로컬 복사본 생성하지 않기, 교육, 액세스 로그	데이터 저장소 유출