"보안은 숨기는 게 아니다"는 말, 정말 맞을까? 모호성을 통한 보안 다시 보기

오래된 보안 격언 하나

보안 공부 좀 해보신 분들이라면 "Security through obscurity is bad"라는 문장 한 번쯤 들어보셨을 거예요. 우리말로 옮기면 "모호성에 기대는 보안은 나쁘다" 정도가 되는데요. 19세기 네덜란드 암호학자 Auguste Kerckhoffs가 "암호 시스템은 키만 비밀이면 충분해야지, 알고리즘 자체가 비밀이어선 안 된다"고 한 말에서 출발한 원칙이에요. 그래서 한동안 업계에선 "숨기는 건 보안이 아니다, 진짜 보안은 알고리즘이 공개돼도 안전한 거다"라는 게 거의 종교처럼 여겨졌죠. mobeigi.com에 올라온 이 글은 바로 그 격언을 정면으로 반박해요. "숨기는 것도 충분히 좋은 보안 전략의 일부다"라고요.

격언이 만들어진 맥락 vs 지금 현실

저자가 짚는 핵심은 이거예요. 케르크호프스 원칙은 "오직 숨김에만 의존하지 말라"는 뜻이지, "절대 숨기지 말라"는 뜻이 아니었다는 거죠. 이게 시간이 지나면서 와전돼서, 지금은 "포트 번호를 22에서 2222로 바꾸는 건 의미 없다"거나 "관리자 페이지 URL을 /admin이 아닌 다른 걸로 두는 건 보안에 도움 안 된다" 같은 식으로 잘못 받아들여지고 있다는 게 저자의 주장이에요.

실제로 SSH 포트 하나만 22에서 다른 번호로 옮겨봐도, 서버 로그에 찍히는 무차별 대입 시도(brute force, 아이디와 비밀번호를 마구잡이로 넣어보는 공격)가 99% 가까이 줄어든다는 건 운영해보신 분들은 다 아실 거예요. 봇들은 대부분 22번 포트만 스캔하거든요. 알고리즘 수준의 보안은 아니지만, 공격 표면(attack surface)을 줄이는 효과는 분명히 있어요. 공격자가 일단 "공격할 대상을 찾는" 단계에서 시간을 쓰게 만드는 것만으로도 가치가 있다는 거죠.

다층 방어, 즉 "디펜스 인 뎁스"의 한 조각

보안 업계에서 자주 쓰는 개념 중에 defense in depth(다층 방어)라는 게 있어요. 이게 뭐냐면, 성벽 하나에 모든 걸 거는 게 아니라 해자, 외성, 내성, 천수각처럼 여러 겹의 방어선을 두는 거예요. 한 겹이 뚫려도 다음 겹이 막아주도록요. 모호성을 통한 보안은 이 다층 구조의 가장 바깥쪽 한 겹으로 보면 딱 좋아요.

예를 들어볼게요. WordPress 사이트 운영하면 기본 로그인 URL이 /wp-admin이잖아요. 이걸 /secret-portal-9f3a로 바꾼다고 해서 보안이 완벽해지진 않아요. 누군가 진짜 작정하고 디렉터리 브루트포싱이나 정찰을 하면 결국 찾아낼 수 있거든요. 하지만 자동화된 봇 트래픽의 99%는 그냥 표준 경로만 두드리고 지나가요. 그 사이 봇 한 마리당 몇 번씩 시도하던 로그인 공격이 사라지고, 진짜 위협만 남게 되니까 모니터링과 대응 리소스를 효율적으로 쓸 수 있게 되는 거예요.

또 다른 예로, API 응답에 서버 정보(Server: nginx/1.18.0 같은 헤더)를 노출하지 않는 것도 모호성의 일종이에요. 버전이 노출되면 공격자가 "아, 이 버전엔 이런 CVE 취약점 있지" 하고 바로 표적 공격을 할 수 있는데, 헤더를 가리면 추가로 핑거프린팅(fingerprinting, 시스템 식별)을 해야 하니까 비용이 올라가요.

그래도 조심해야 할 함정

물론 저자도 모든 모호성이 좋다고는 안 해요. 위험한 패턴 두 가지가 있어요. 첫째, 하드코딩된 비밀이 그래요. 소스코드에 API 키를 박아두고 "리포지토리가 비공개니까 괜찮아" 하는 건 진짜로 위험해요. 깃 히스토리에 남아 있어서 협업자 한 명만 유출돼도 터지거든요. 둘째, 암호 알고리즘을 직접 만드는 것도 안 돼요. "우리만의 비밀 암호"는 거의 100% 깨져요. 검증된 표준(AES, RSA, Argon2 같은) 쓰는 게 정답이에요.

한국 개발자 입장에서는

실무에 바로 적용해볼 만한 게 꽤 많아요. SSH 포트 변경, 관리자 페이지 경로 난독화, HTTP 헤더에서 서버/프레임워크 정보 제거, 에러 메시지에서 스택 트레이스 숨기기 같은 것들요. 한국에서는 특히 공공기관이나 금융 쪽 보안 가이드가 "표준을 따르라"는 명시적인 요구가 많아서 모호성 전략을 부수적인 것으로 치부하는 경향이 있는데요, 취약점 스캐너 트래픽을 줄이고 SOC(보안관제센터)의 노이즈를 줄이는 실용적 효과를 생각하면 분명 가치 있는 접근이에요.

마무리

결국 정답은 "오직 숨김에만 기대지 말되, 숨길 수 있는 건 숨겨라"예요. 진짜 방어선은 강력한 인증, 최소 권한, 패치 관리 같은 본질적인 것들에 있지만, 그 앞에 모호성 한 겹을 더 둔다고 손해볼 일은 없거든요. 여러분 회사에서는 어떤 모호성 전략을 쓰고 계신가요? 혹은 "이건 의미 없다"며 포기한 게 있다면 다시 검토해볼 만한지 한번 생각해보세요.