Secure by Default 제품 설계: 안전한 기본값이 고객 지원을 줄인다

제품 보안 사고의 상당수는 복잡한 취약점보다 “가능했기 때문에 켜 둔” 설정에서 시작한다. 새 프로젝트가 공개로 생성되고, 첫 사용자가 영구 최고관리자가 되며, 감사 로그는 별도 구매 항목이고, API 키는 만료되지 않는다면 고객은 모든 문서를 정확히 읽어야만 안전해진다. 이 구조는 보안 책임과 지원 비용을 고객에게 떠넘긴다.

안전한 기본값은 모든 기능을 막는 것이 아니다. 대부분의 사용자가 별도 판단 없이 시작해도 피해 범위가 제한되고, 더 위험한 설정은 목적과 영향을 이해한 사용자가 의식적으로 선택하도록 만드는 것이다.

기본값 인벤토리를 만든다

기능별로 “처음 생성됐을 때의 상태”를 표로 관리한다.

영역	안전한 기본 방향	약화 시 필요한 절차
공개 범위	비공개 또는 조직 내부	공개 대상·검색 노출·민감정보 경고
관리자 권한	최소 역할, 별도 승격	재인증, 이유, 시간 제한, 감사 로그
인증	강한 기본 정책과 안전한 복구	위험 감소 설명, 관리자 승인
API 키	최소 범위, 만료, 한 번만 표시	장기 키 사유, 소유자, 회전일
외부 공유	만료·다운로드 제한	수신자·기간·권한 확인
감사 로그	핵심 관리 이벤트 기본 활성화	비활성화 권한 제한과 경보
데이터 내보내기	제한된 역할과 재인증	대량·민감 데이터 추가 승인
통합·웹훅	검증된 목적지와 최소 이벤트	비밀값 보호, 재시도·서명 설정

이 표에는 현재 기본값뿐 아니라 기존 고객의 분포, 변경 소유자, 마지막 검토일을 함께 넣는다. 문서에 “권장”이라고 쓰고 실제 생성 화면은 위험한 값을 선택해 두면 안전한 기본값이 아니다.

제품 요구사항으로 바꾸는 질문

새 기능 기획 단계에서 다음 질문을 필수로 답한다.

• 설정하지 않았을 때 누가 볼 수 있고 무엇을 할 수 있는가.
• 실수로 가장 넓은 권한을 선택하기 쉬운 지점은 어디인가.
• 위험한 설정을 변경한 사람과 시각을 고객이 확인할 수 있는가.
• 관리자가 설정을 되돌릴 수 있고 영향 범위를 알 수 있는가.
• 기능을 사용하지 않는 고객에게 공격 표면이 생기지 않는가.
• 엔터프라이즈 정책으로 조직 전체 기본값을 강제할 수 있는가.
• 안전 기능이 별도 고가 요금제에만 묶여 있지 않은가.

보안팀이 출시 직전에 체크리스트만 보는 구조로는 늦다. 제품 요구사항, API 스키마, UI 문구, 기본 구성 파일, 마이그레이션 계획에 같은 기본값이 반영돼야 한다.

위험한 선택에는 마찰을 의도적으로 둔다

모든 마찰이 나쁜 것은 아니다. 조직 전체 공개, 감사 로그 중지, 최고관리자 키 생성, MFA 정책 완화처럼 영향이 큰 행동에는 다음 통제를 적용한다.

• 현재 사용자 재인증
• 영향받는 데이터·사용자·기간의 구체적 표시
• 단순 “확인” 대신 변경 내용을 다시 선택하게 하는 확인
• 이유와 변경 티켓 입력
• 자동 만료 또는 다음 검토일
• 보안·관리자 알림
• 변경 전후 값과 행위자 감사 로그

경고창을 많이 띄우는 것만으로는 부족하다. 사용자가 습관적으로 넘기지 않도록 위험한 행동에만 집중하고, 안전한 대안 버튼을 기본 선택으로 둔다.

기존 고객을 안전하게 옮기는 방법

기본값을 바꿔도 기존 설정은 그대로 남는 경우가 많다. 반대로 모든 고객을 즉시 강제 변경하면 업무 중단과 신뢰 하락이 생길 수 있다. 마이그레이션은 다음 순서가 현실적이다.

1. 현재 설정 분포와 실제 사용량을 측정한다.
2. 영향을 받는 고객군과 위험 등급을 분류한다.
3. 새 고객에는 안전한 기본값을 즉시 적용한다.
4. 기존 고객에게 변경 이유, 일정, 사전 점검 방법을 알린다.
5. 관찰 모드 또는 자동 수정 미리보기를 제공한다.
6. 저위험 고객부터 단계적으로 적용한다.
7. 업무 차단 지표와 지원 문의를 보며 속도를 조절한다.
8. 예외에는 소유자·사유·만료를 붙이고 장기적으로 줄인다.

마이그레이션 중에는 설정 변경을 API와 UI 어느 경로에서 해도 같은 정책이 적용돼야 한다. 이전 SDK나 숨은 관리자 API가 위험한 기본값을 계속 만들지 않는지 확인한다.

실패 모드와 탐지 신호

실패 모드	탐지 신호	확인할 내용
UI만 안전하고 API는 위험	API로 만든 자원의 공개·권한 설정이 다름	서버 측 기본값이 단일 소스인가
권장값만 문서화	신규 고객의 위험 설정 비율이 줄지 않음	생성 시 실제 선택값이 안전한가
기존 고객 영구 방치	오래된 테넌트에 공개·무기한 키가 집중	마이그레이션 계획과 예외 만료가 있는가
보안 기능 유료화	기본 요금제 고객만 사고·문의가 집중	핵심 방어가 모든 고객에게 제공되는가
경고 피로	고위험 변경 승인 시간이 지나치게 짧음	경고를 위험 행동에만 제한했는가
복구 불가능한 강제 변경	고객 업무 중단 후 수동 DB 수정 필요	롤백과 호환 기간을 준비했는가
감사 로그 비활성화	설정 변경 후 행위자를 확인하지 못함	핵심 이벤트를 고객이 끌 수 없게 했는가

예시: 새 워크스페이스의 외부 공유

새 워크스페이스가 생성될 때 “링크를 아는 모든 사람”이 기본값이라면 사용자는 편리함을 느끼지만 내부 문서가 검색·전달될 위험이 커진다. 안전한 기본 설계는 다음과 같다.

• 기본은 조직 구성원만 접근한다.
• 외부 공유는 특정 수신자와 만료일을 요구한다.
• 민감 분류 문서는 외부 공유를 추가 승인 대상으로 둔다.
• 링크 사용, 다운로드, 권한 변경을 감사 로그에 남긴다.
• 관리자는 조직 전체 외부 공유 정책을 강제할 수 있다.
• 이미 공개된 링크를 한 번에 조회하고 폐기할 수 있다.

이 원칙은 API 제품에도 동일하다. 인증, 감사 로그, 제한, 버전 정책을 고객 증거로 묶는 방법은 API 제품 보안 로드맵에서 이어진다.

릴리스 게이트

기능 출시 전

• UI, API, SDK, IaC의 기본값이 모두 같은가.
• 생성·복제·가져오기·마이그레이션 경로를 각각 테스트했는가.
• 가장 넓은 권한과 공개 범위가 자동 선택되지 않는가.
• 위험 설정 변경에 재인증·감사·알림이 있는가.
• 고객이 현재 위험 설정을 일괄 조회할 수 있는가.
• 비상 롤백과 기존 클라이언트 호환성을 확인했는가.

출시 후

• 신규 자원의 안전 기본값 유지율
• 위험한 설정으로 바꾼 비율과 변경 이유
• 무기한 예외·만료 초과·미소유 설정 수
• 설정 관련 보안 사고와 고객지원 문의
• 조직·요금제·생성 경로별 설정 차이
• 마이그레이션 성공·롤백·업무 차단률

지표의 목표를 “위험 설정 0건”으로 두면 사용자가 비공식 우회 경로를 만들 수 있다. 업무상 필요한 예외는 허용하되 가시성과 만료를 확보하는 것이 현실적이다.

책임 분담

제품 책임자는 기본 사용자 여정과 마이그레이션 우선순위를 정하고, 보안팀은 위협 모델과 최소 통제를 정의한다. 개발팀은 서버 측 기본값과 우회 불가능한 검증을 구현하며, 고객지원은 경고 문구와 복구 절차가 이해 가능한지 확인한다. 영업·고객성공팀은 안전 기능을 선택적 부가 기능처럼 판매하지 않도록 고객 약속을 정리한다.

코드 변경을 안전하게 승인하는 통제는 브랜치 보호와 CODEOWNERS, 경계 계층의 기본 정책은 WAF와 API 게이트웨이와 연결할 수 있다.

검수 체크리스트

• 새 고객이 아무 설정도 하지 않아도 최소 권한·비공개 상태인가.
• 핵심 감사 로그와 보안 알림이 기본 활성화돼 있는가.
• API 키·공유 링크·승격 권한에 만료가 있는가.
• 위험한 변경은 재인증과 명확한 영향 확인을 요구하는가.
• 모든 생성 경로가 동일한 서버 측 기본값을 사용하는가.
• 기존 고객의 위험 설정을 탐색하고 단계적으로 줄이는가.
• 예외는 이유·소유자·만료·보완 통제를 갖는가.
• 설정 변경과 롤백을 고객과 운영팀이 감사할 수 있는가.

참고 기준

• CISA Secure by Design
• NIST Secure Software Development Framework SP 800-218
• OWASP Application Security Verification Standard

최종 판단

Secure by Default는 보안 설정 화면을 늘리는 일이 아니라 사용자가 아무것도 하지 않았을 때의 결과를 책임지는 제품 설계다. 안전한 서버 측 기본값, 위험한 변경의 의도적 마찰, 감사 가능한 예외, 기존 고객 마이그레이션이 함께 있어야 한다. 가장 먼저 할 일은 신규 자원 생성 경로를 전부 열어 실제 기본 공개 범위·권한·로그·만료 값을 한 표로 비교하는 것이다.