Cloudflare 계정·권한, 무엇부터 점검해야 합니까

Cloudflare를 도입한 조직에서 보안 점검을 하면 대개 방화벽 규칙, 차단 정책, DNS 설정처럼 “무엇을 막고 있는가”에 시간을 씁니다. 그 자체는 옳은 일이지만, 한 가지가 자주 비어 있습니다. 그 규칙들을 바꿀 수 있는 사람과 열쇠가 어떻게 관리되고 있는가입니다.

방어 규칙을 아무리 촘촘히 짜도, 그 규칙을 조작하는 계정이 넓게 열려 있으면 규칙은 언제든 되돌려질 수 있습니다. 이 글은 Cloudflare로 무엇을 막느냐가 아니라, 그 Cloudflare를 조작하는 계정·권한·API 키 자체를 어떻게 지키는가를 점검 항목 형태로 정리합니다. 항목마다 왜 중요한지, 방치하면 무엇이 열리는지, 어떻게 확인하고 조치하는지를 함께 적었습니다.

방어 규칙과 그 규칙을 바꿀 열쇠는 다르다

보안 설정을 검토하는 자리와 계정을 검토하는 자리는 성격이 다릅니다. 앞쪽은 “외부의 공격을 무엇으로 거르는가”이고, 뒤쪽은 “그 거름망을 누가 만지고 지울 수 있는가”입니다. 두 가지는 붙어 있어 보이지만 관리하는 대상이 완전히 다릅니다.

이 구분이 실무에서 왜 중요하냐면, 방어 규칙은 눈에 보이고 자주 손대는 대상이라 자연스럽게 관리되는 반면, 계정과 토큰은 한 번 만들어 둔 뒤 잊히기 쉽기 때문입니다. 처음 계정을 만든 사람이 아직 그대로 최고 권한을 쥐고 있고, 몇 년 전 자동화용으로 발급한 키가 여전히 살아 있으며, 그 키가 무엇을 할 수 있는지 아무도 정확히 답하지 못하는 상태 ─ 이것이 방어 규칙과 무관하게 존재하는 위험입니다.

아래 항목들은 특정 공격을 막기 위한 것이 아닙니다. 사고가 났을 때 피해 범위를 좁히고, 무슨 일이 있었는지 추적할 수 있게 하는 바닥입니다. 하나씩 짚겠습니다.

① 로그인에 다단계 인증(2FA)을 강제한다

왜 중요한가. 계정 로그인이 아이디와 비밀번호만으로 이뤄지면, 그 비밀번호 하나가 곧 모든 설정으로 가는 열쇠입니다. 비밀번호는 재사용·유출·피싱으로 상대적으로 쉽게 넘어갈 수 있는 요소이고, 넘어간 사실이 즉시 드러나지도 않습니다. 다단계 인증(2FA, 또는 MFA)은 비밀번호에 더해 “본인이 가진 것”을 한 번 더 요구해서, 비밀번호 하나가 새어도 그것만으로는 로그인이 되지 않게 합니다.

방치하면 무엇이 열리는가. 2FA가 없는 계정은 비밀번호가 뚫린 순간 방어 규칙 전체를 조작할 수 있는 자리로 바로 이어집니다. 공격자가 WAF 규칙을 끄거나, DNS를 자기 쪽으로 돌리거나, 새 관리자를 추가하는 일이 로그인 한 번으로 가능해집니다. 더 곤란한 것은, 일부 구성원만 2FA를 켜고 일부는 켜지 않은 상태입니다. 가장 약한 계정 하나가 전체의 문턱이 되기 때문에, “권장은 했다”는 상태로는 방어가 되지 않습니다.

어떻게 확인·조치하는가. Cloudflare는 인증 앱이 생성하는 시간 기반 코드(TOTP)와 보안 키(하드웨어 키나 기기 내장 인증기) 방식을 지원합니다. 핵심은 개인에게 맡기지 않고 강제하는 것입니다. Cloudflare 공식 문서에 따르면 최고 권한 관리자(Super Administrator)는 계정 차원에서 2FA 강제(2FA Enforcement) 를 켤 수 있으며, 강제가 켜진 계정에서는 구성원이 2FA를 설정하기 전에는 참여가 되지 않습니다. 즉 강제를 켜 두는 것 자체가 “모두 켰는가”를 확인하는 절차를 대신합니다. 켜는 위치와 지원 방식은 화면 구성에 따라 조금씩 다르므로 Cloudflare의 2FA 문서에서 확인하십시오.

② 자동화는 Global API Key가 아니라 API 토큰으로

왜 중요한가. 사람은 화면으로 로그인하지만, 배포 스크립트·모니터링·연동 도구 같은 자동화는 API로 Cloudflare를 조작합니다. 이때 무엇을 열쇠로 쓰느냐가 갈립니다. Global API Key는 오래된 인증 방식으로, 그 사용자가 접근할 수 있는 모든 자원에 접근합니다. 반면 API 토큰은 필요한 권한만 담아 발급할 수 있습니다.

방치하면 무엇이 열리는가. Global API Key의 문제는 범위를 좁힐 수 없다는 데 있습니다. Cloudflare 문서는 “Global API key는 사용자의 모든 자원에 접근하며, 이 때문에 운영 자원과 비운영 자원을 함께 다루는 사용자가 이 키로 비운영 자원에 안전하게 접근하는 것이 불가능하다”고 설명하고, 그래서 “신규 고객에게는 권장하지 않는다” 고 명시합니다. 이 키를 스크립트나 CI 설정, 서드파티 도구에 넣어 두면, 그 키 한 줄이 새는 순간 계정 전체가 노출됩니다. DNS만 손대는 자동화에 붙여 뒀더라도 유출 시 열리는 것은 DNS만이 아닙니다.

어떻게 확인·조치하는가. 지금 자동화에 무엇을 쓰고 있는지부터 확인하십시오. Global API Key를 쓰고 있다면 각 자동화가 실제로 필요로 하는 권한을 적고, 그 권한만 담은 API 토큰을 발급해 교체합니다. 한 번에 전부 바꾸기보다 자동화 하나씩 옮기고 확인하는 편이 안전합니다. 자세한 권장 사항은 Cloudflare의 API keys 문서에 정리돼 있습니다.

③ 토큰의 범위를 좁힌다 ─ 권한·자원·기간·출처 IP

왜 중요한가. API 토큰으로 옮기는 것만으로 끝이 아닙니다. 토큰의 값어치는 얼마나 좁게 만들었는가에서 나옵니다. 넓은 권한을 담은 토큰은 Global API Key와 실질적으로 다르지 않습니다. Cloudflare 토큰은 네 가지 축으로 범위를 좁힐 수 있습니다.

• 권한 ─ 특정 기능에 대해 읽기만 허용할지, 편집까지 허용할지를 정합니다. 읽어서 확인만 하는 자동화라면 편집 권한을 담지 않습니다.
• 자원 ─ 계정 전체가 아니라 특정 존(도메인) 하나로 대상을 한정합니다. 한 도메인의 DNS만 다루는 토큰이 다른 도메인을 건드리지 못하게 합니다.
• 만료(TTL) ─ 토큰에 유효 기간을 부여해 정해진 시점에 스스로 만료되게 합니다. 임시 작업용 토큰이 영구히 남는 것을 막습니다.
• 출처 IP ─ 특정 IP 주소에서 온 요청만 그 토큰을 쓸 수 있게 제한합니다(Client IP Address Filtering).

방치하면 무엇이 열리는가. 범위를 좁히는 목적은 “뚫리지 않게” 하는 것이 아니라 하나가 뚫려도 피해를 그 범위에 가두는 것입니다. 넓은 토큰 하나가 새면 계정 전체가 위태롭지만, DNS 읽기만 담긴 존 한정 토큰이 새면 그 존의 DNS를 읽는 것까지가 피해의 상한입니다. 만료가 없는 토큰은 유출돼도 스스로 사라지지 않아, 발급 사실조차 잊힌 채 계속 유효합니다.

어떻게 확인·조치하는가. 발급된 토큰마다 “이 토큰은 무엇을, 어디에, 언제까지, 어디서부터 할 수 있는가”에 답해 보십시오. 네 가지 중 비어 있는 축이 곧 넓혀진 범위입니다. 토큰 발급 시 지정할 수 있는 범위의 전체는 Cloudflare의 API 토큰 생성 문서에 있습니다.

④ 사람에게는 역할을 나눠 최소 권한만 준다

왜 중요한가. 멤버를 초대할 때 가장 쉬운 선택은 최고 권한을 주는 것입니다. 권한이 모자라 일이 막히는 상황을 피하려다 보니 그렇게 됩니다. 하지만 편의로 넓힌 권한은 그 사람이 실제로 하는 일보다 훨씬 넓게 열려 있게 되고, 그 상태가 정리되는 계기는 좀처럼 오지 않습니다.

방치하면 무엇이 열리는가. DNS만 관리하면 되는 담당자가 결제·멤버 관리·모든 설정 변경 권한까지 쥐고 있으면, 그 계정이 실수하거나 탈취될 때 열리는 범위가 담당 업무와 무관하게 넓어집니다. 대행사나 외부 인력에게 최고 권한을 준 경우는 특히 그렇습니다. 그들이 맡은 일은 한 도메인의 설정이어도, 손댈 수 있는 것은 계정 전체가 됩니다.

어떻게 확인·조치하는가. Cloudflare는 계정 전체에 적용되는 역할 외에 도메인 단위, 자원 단위로 범위를 좁힌 역할을 제공하며, 계정을 보기만 하는 최소 접근(Minimal Account Access) 역할도 있습니다. 각 구성원에게 “이 사람이 실제로 하는 일에 필요한 최소 역할은 무엇인가”를 기준으로 다시 부여하십시오. 최소 권한이라는 원칙 자체는 Zero Trust와 VPN의 차이에서 다룬 접근 통제의 상위 원칙과 같지만, 여기서 대상은 애플리케이션이 아니라 Cloudflare 관리 콘솔 자체라는 점이 다릅니다. 역할별 권한 범위는 Cloudflare의 Roles 문서에서 확인할 수 있습니다.

⑤ 최고 권한(Super Administrator)을 최소로 둔다

왜 중요한가. 최고 권한 역할(Super Administrator)은 계정에서 할 수 있는 거의 모든 것을 할 수 있습니다. Cloudflare 문서 기준으로 이 역할은 모든 Cloudflare 설정 편집, 구매, 결제 정보 갱신, 멤버 관리, 계정 소유 API 토큰 생성이 가능하고, 다른 최고 권한 관리자의 접근을 회수하는 것까지 할 수 있습니다. 편의로 이 역할을 여럿에게 주면, 계정 전체를 좌우할 수 있는 열쇠의 수만 늘어납니다.

방치하면 무엇이 열리는가. 최고 권한 계정은 그 하나가 탈취되면 계정 전체가 넘어가는 자리입니다. 최고 권한이 다섯 명이면 공격자가 노릴 수 있는 완전한 열쇠가 다섯 개라는 뜻이고, 그중 가장 약하게 관리되는 하나가 전체의 위험 수준을 정합니다. 앞의 ①에서 2FA 강제가 특히 중요한 이유도 여기에 있습니다 ─ 최고 권한일수록 로그인 보호가 부실할 때 잃는 것이 큽니다.

어떻게 확인·조치하는가. 지금 최고 권한을 가진 사람이 몇 명이고 각각 그 권한이 실제로 필요한지 확인하십시오. 대부분의 일은 그보다 좁은 역할로 처리됩니다. 참고로 Administrator 역할은 넓은 접근을 갖되 멤버 관리와 결제는 하지 못하므로, 운영은 하지만 사람과 돈은 건드릴 필요가 없는 담당자에게 적합합니다. 최고 권한은 반드시 필요한 최소 인원으로 좁히고, 그 인원에는 2FA를 예외 없이 적용하십시오.

⑥ 감사 로그로 누가·언제·무엇을 바꿨는지 추적한다

왜 중요한가. 앞의 항목들이 “누가 무엇을 할 수 있는가”를 좁히는 일이라면, 감사 로그는 “실제로 무엇이 일어났는가”를 남기는 일입니다. 권한을 아무리 잘 나눠도 허용된 범위 안에서 일어난 변경은 막지 못하므로, 무슨 일이 있었는지 되짚을 기록이 별도로 필요합니다.

방치하면 무엇이 열리는가. 로그를 보지 않으면 규칙이 언제 바뀌었는지, 그 변경이 의도된 것이었는지, 누가 했는지를 사고가 난 뒤에도 답할 수 없습니다. 설정이 어느 날 조용히 바뀌어 있는데 그것이 정상 작업이었는지 침해였는지 구분할 근거가 없는 상태는, 사고 자체보다 대응을 어렵게 만듭니다.

어떻게 확인·조치하는가. Cloudflare 감사 로그는 별도로 켜는 기능이 아니라 로그인, 존 설정 변경 같은 계정 차원의 행위를 기본으로 기록하며, 공식 문서 기준으로 18개월 동안 보존됩니다. 다만 로그가 남는 것과 그것을 보는 것은 다른 일입니다. 정기적으로 훑어 변경의 평소 모습을 익혀 두어야, 사고 시점에 로그가 판단 자료로 쓰입니다. 기록 대상과 보존에 관한 세부는 Cloudflare의 감사 로그 문서에 있습니다.

⑦ 접근과 토큰을 회수하는 절차를 둔다

왜 중요한가. 권한을 주는 일에는 계기가 있지만 회수하는 일에는 계기가 없습니다. 사람이 들어올 때는 접근을 부여하는 명확한 시점이 있는 반면, 나갈 때는 업무 인수인계에 밀려 접근 회수가 뒤로 미뤄지거나 잊힙니다. 그래서 회수는 절차로 정해 두지 않으면 거의 항상 빠집니다.

방치하면 무엇이 열리는가. 퇴사자의 계정, 계약이 끝난 대행사의 멤버 자격, 교체된 담당자가 발급했던 토큰이 그대로 살아 있으면, 이미 관계가 끝난 주체가 계속 설정을 조작할 수 있는 상태가 됩니다. 특히 API 토큰은 사람과 달리 화면에 드러나지 않아, 발급자가 떠난 뒤에도 남아 있다는 사실조차 인지되지 않기 쉽습니다.

어떻게 확인·조치하는가. 퇴사·계약 종료·담당자 교체·대행사 변경 같은 시점을 회수의 계기로 미리 정하고, 그때 확인할 목록을 만들어 두십시오. 멤버 자격 제거만이 아니라 그 사람이 발급했던 토큰까지 함께 봐야 합니다. 정기적으로 멤버 목록과 살아 있는 토큰을 대조해 “이건 누구 것이고 아직 필요한가”에 답하지 못하는 항목을 정리하는 것도 방법입니다. 규칙을 바꿀 권한을 다룬다는 점에서, 이 회수 대상에는 Cloudflare WAF가 막는 것과 막지 못하는 것에서 다룬 방어 규칙을 조작할 수 있는 접근이 모두 포함됩니다.

여기에 하나 덧붙이면, 토큰 비밀과 자격증명 자체를 어떻게 보관하는가입니다. Cloudflare는 API 토큰의 비밀 값을 발급 시 한 번만 보여 주며, 다른 사람이 접근할 수 있는 곳에 평문으로 저장하지 말라고 안내합니다. 그 값을 아는 누구든 토큰이 허용한 작업을 그대로 할 수 있기 때문입니다. 스크립트나 설정 파일, 채팅 기록에 토큰이 평문으로 남아 있지 않은지 함께 확인하십시오.

우리에게 무엇부터인가

항목이 많아 보이지만 순서는 분명합니다. 먼저 목록을 만드는 것이 시작입니다. 지금 이 Cloudflare 계정에 접근할 수 있는 사람이 누구이고, 살아 있는 API 키·토큰이 무엇이며, 각각의 권한 범위가 무엇인지를 적을 수 있어야 합니다. 이 목록을 적지 못한다면 그것이 지금 상태입니다 ─ 무엇을 좁혀야 하는지 판단할 근거 자체가 없는 것이므로, 위의 어떤 항목도 목록 없이는 진행되지 않습니다.

목록이 만들어지면 값이 큰 것부터 손댑니다. 대체로 순서는 이렇습니다.

1. 모든 로그인에 2FA를 강제합니다. 열쇠가 몇 개든 그 열쇠 각각의 기본 보호를 먼저 세우는 일입니다.
2. 최고 권한을 최소 인원으로 좁힙니다. 완전한 열쇠의 수를 줄이는 것이 피해 범위를 가장 크게 줄입니다.
3. 자동화의 Global API Key를 범위를 좁힌 토큰으로 교체합니다. 사람보다 잊히기 쉬운 열쇠부터 정리합니다.
4. 회수 절차와 정기 점검을 자리 잡게 합니다. 한 번의 정리가 아니라 유지되는 상태로 만드는 단계입니다.

빌드업웍스의 운영 경험에서는, 이 중 목록화 단계를 건너뛰고 개별 항목부터 손대는 경우가 가장 자주 되돌아옵니다. 무엇이 열려 있는지 모르는 상태에서 몇 개만 좁히면, 좁히지 못한 나머지가 그대로 남아 있다는 사실조차 드러나지 않기 때문입니다. 반대로 목록이 한 번 만들어지면 이후 점검은 그 목록을 갱신하는 일이 되어 훨씬 가벼워집니다.

다음 단계

지금 계정이 어느 상태에 있는지부터 확인하시는 것이 순서상 먼저입니다. 보안 진단에는 접근 통제와 인증을 다루는 항목이 포함돼 있어, 이 글에서 짚은 기준을 자신의 환경에 대입해 보실 수 있습니다. 연락처를 남기지 않아도 결과는 바로 확인하실 수 있습니다.

계정·권한 정리를 접근 통제와 최소 권한 전반과 함께 잡고 싶으시면, 어디까지가 저희 몫이고 어디부터 별도인지 나눠 적어 둔 통합 보안 서비스 범위를 먼저 보십시오. 지금 구조에서 무엇부터 좁히는 것이 맞을지 함께 정리하고 싶으시면 상담 신청으로 연락 주십시오.

참고 자료

• Cloudflare Docs — Two-factor authentication (2FA)
• Cloudflare Docs — API keys
• Cloudflare Docs — Create an API token
• Cloudflare Docs — Roles
• Cloudflare Docs — Review audit logs