주요 내용
- 클라우드 보안 표준은 인증 및 확인서부터 규정, 계약, 통제 프레임워크에 이르기까지 총 5가지 이행 유형으로 분류됩니다.
- ISO/IEC 27017은 2015년 이후 처음으로 전면 개정되었으며, FedRAMP는 규정집을 전면 개정했고, CSA는 CCM v4.1을 발표했습니다.
- 패치 관련 조항은 거의 모든 표준에 포함되어 있지만, 이에 대한 명확한 기한을 명시한 표준은 극소수에 불과합니다.
- 대부분의 감사 관련 문제는 평가 기간 사이에 점차 쌓이게 되며, 이 과정에서 패치 미적용 건수가 늘어나고 구성 설정이 점차 어긋나게 됩니다.
오늘날 현대 기업의 운영 기반 중 상당 부분은 해당 기업이 소유하지 않은 인프라에 의존하고 있으며, 이러한 변화로 인해 보안에 대한 책임 소재가 바뀌었습니다. 또한 이로 인해 준수해야 할 규정도 몇 배로 늘어났습니다. 보안 팀이 가 한 번에 준수해야 하는 규정들의 수가 기하급수적으로 늘어났습니다. 클라우드 보안 표준은 바로 이러한 규정들을 문서화한 것입니다.
이 기사에서는 클라우드 보안 표준이 무엇인지, 표준의 유형이 왜 중요한지, 그리고 2026년 클라우드 규정 준수 프로그램에서 가장 중요한 14가지 표준이 무엇인지 다룹니다.
클라우드 보안이란 무엇인가요?
클라우드 보안 는 클라우드 환경 내의 워크로드, 신원 및 데이터를 보호하는 일련의 통제 수단을 말하며, 이는 대개 타사가 운영하는 서버를 의미합니다. 이는 IaaS, PaaS 및 SaaS 전반에 걸쳐 구성, 암호화, 액세스 관리, 패치 적용 및 모니터링을 포괄합니다. IaaS의 경우, 공급자가 물리적 호스트와 하이퍼바이저를 관리하며, 사용자는 게스트 OS부터 위쪽의 거의 모든 부분을 소유합니다. SaaS에서는 제공업체가 스택의 대부분을 운영하므로, 사용자의 역할은 신원, 테넌트 구성, 그리고 사용자가 데이터를 어떻게 처리하는지로 좁혀집니다. PaaS는 이 둘의 중간에 위치합니다.
클라우드 보안 표준이란 무엇인가요?
클라우드 보안 표준은 클라우드 환경에서 ‘충분히 안전한’ 상태가 어떤 모습인지 정의하는 공식적으로 발표된 요구사항으로, 감사관과 규제 당국이 검증할 수 있는 구체적인 기준을 제공합니다. 일부 표준은 유효 기간이 정해져 있고 갱신되는 실제 인증서를 발급합니다. 일부는 합격 또는 불합격 판정 대신 인증 보고서를 발급합니다. 일부는 법적 효력을 가지며, 위반 시 벌금이 부과됩니다. 그 외의 표준은 고객, 감사관 또는 자체 위험 평가 결과의 권고에 따라 조직이 자발적으로 채택하는 지침입니다.
이 마지막 범주는 사람들이 흔히 말하는 클라우드 보안 프레임워크인 NIST CSF, CSA의 클라우드 제어 매트릭스(CCM), 그리고 인증보다는 지침 제공을 목적으로 구축된 유사한 참조 세트들과 겹칩니다. 이러한 중복은 실제로 존재하며, 양방향으로 나타납니다. NIST CSF와 CCM 모두 자발적 적용을 지향한다고 명시하고 있음에도 불구하고, 수많은 “표준” 정리 자료에 이 두 가지가 포함되어 있습니다.
이 가이드에서는 “표준”이라는 용어를 클라우드 컴퓨팅의 보안 요구 사항을 포괄하는 총칭으로 사용합니다. 클라우드 컴퓨팅 에서 광범위하게 적용되는 보안 요구 사항을 포괄하는 총칭으로 사용하며, “표준”과 “프레임워크” 사이에 엄격한 경계를 그리는 대신 각 항목을 실제로 어떻게 적용되는지(인증, 증명, 규제, 계약상 요구 사항 또는 통제 프레임워크)에 따라 분류합니다.
클라우드 보안 표준이 중요한 이유
이유는 두 가지입니다. 수익을 확보할 수 있을 뿐만 아니라 위험도 관리할 수 있기 때문입니다. 많은 기업 구매자들은 SOC 2 보고서나 ISO 인증서가 제출되지 않으면 계약을 체결하지 않습니다. 또한, 인증서 보유 여부와 관계없이 GDPR이나 HIPAA 위반 시 규제 당국의 제재를 받을 수 있습니다.
규정 준수를 최우선으로 여기는 조직에게 있어, 표준은 단순히 선의를 표명하는 것 이상의 실질적인 역할을 합니다. 표준은 “우리는 보안을 중요하게 여긴다”는 메시지를 규제 당국, 감사인 또는 조달 팀이 실제로 확인할 수 있는 통제 지표로 전환해 줍니다.
현실 점검: 감사를 통과했다고 해서 그 사이 매일 통제 체계가 제대로 작동한다는 증거는 되지 않습니다. ISO 27001 정기 감사는 대개 1년에 한 번 실시되며, SOC 2 Type II 관찰 기간만 해도 1년 중 대부분을 차지할 수 있습니다. 이러한 점검 시점 사이에는 패치 미적용 건수가 쌓이고, 구성 설정이 변경되며, 지난 감사에서 다루지 않은 범위 밖에서 새로운 서비스가 가동되기도 합니다. 지속적인 모니터링이 없다면, 이러한 문제 중 상당수는 다음 평가가 실시될 때까지 드러나지 않을 것입니다. 현재 알려진 클라우드 보안 위협 목록 목록은 바로 그 공백 기간 동안 쌓이기 쉬운 문제들을 다루고 있습니다.
클라우드 보안 표준 14선
어떤 표준을 검토하고 있는지에 따라 실제로 취해야 할 조치가 결정됩니다. 이 다섯 가지 유형을 혼동하다 보니, 팀들은 독립된 인증으로 존재하지 않는 “ISO 27017 인증서”를 고객에게 약속하거나, CSF에는 인증 절차가 전혀 없음에도 불구하고 감사관에게 “NIST CSF 인증을 받았다”고 말하는 상황이 발생합니다.
| 표준 | 운영 기구 | 유형 | 누가 그런 게 필요하겠어? |
| ISO/IEC 27017:2026 | ISO/IEC | 통제 체계 (ISO/IEC 27001 감사 범위 내에서 평가됨) | 클라우드 서비스 제공업체와 고객 |
| SOC 2 | AICPA | 인증서 | 미국 기업을 대상으로 제품을 판매하는 SaaS 및 서비스 기업 |
| GDPR | EU / 각국 개인정보보호위원회 | 규정 | EU 내 거주자의 개인정보를 처리하는 모든 자 |
| HIPAA | 미국 보건복지부(HHS) 시민권 보호국 | 규정 | 적용 대상 기관 및 업무 협력사 |
| PCI DSS v4.0.1 | PCI 보안 표준 위원회 | 계약상 기준 | 카드 데이터를 저장, 처리 또는 전송하는 모든 자 |
| ISO/IEC 27001:2022 | ISO/IEC | 인증 | 인증된 ISMS가 필요한 조직 |
| ISO/IEC 27018:2025 | ISO/IEC | 통제 체계 (ISO/IEC 27001 감사 범위 내에서 평가됨) | 개인정보 처리자로서 역할을 수행하는 퍼블릭 클라우드 제공업체 |
| CSA STAR / CCM v4.1 | 클라우드 보안 연합 | STAR 인증 또는 자격을 갖춘 제어 프레임워크 | STAR 레지스트리에 보증 정보를 게시하는 제공자 |
| NIST SP 800-53 릴리스 5.2.0 | NIST | 통제 체계 (통제 목록) | 미국 연방 시스템 및 FedRAMP 통제 조치를 승계하는 모든 주체 |
| NIST CSF 2.0 | NIST | 통제 체계 (자발적) | 보안 프로그램을 구축하는 모든 조직 |
| FedRAMP | FedRAMP PMO / GSA | 인증 | 미국 연방 기관에 판매된 클라우드 서비스 |
| NIS2 지침 | EU / 각국 당국 | 지침 (국내법 전환을 통해 시행되는 법률) | EU 18개 부문 전반에 걸친 핵심적이고 중요한 주체들 |
| DORA | EU / 유럽 감독 당국 | 규정 | 중요 ICT 공급업체를 감독하는 EU 금융 기관들 |
| CIS 벤치마크 및 제어 기준 v8.1 | 인터넷 보안 센터 | 통제 체계 (안전장치 및 구성 기준) | 클라우드 인프라를 강화하는 모든 팀 |
1. ISO/IEC 27017 (2026년판)
ISO와 IEC는 정보 보안에 관한 공동 기술 위원회를 통해 이 표준을 공동으로 관리하고 있으며, 2026년판 은 단순한 부분 개정이 아닌 전면적인 개편입니다. 2026년 7월에 발간된 이 표준은 2015년 초판을 완전히 대체하며, 기존에 기반했던 2013년 구조 대신 ISO/IEC 27002:2022의 통제 구조로 전환합니다.
The 2015년판 에는 CLD 번호가 부여된 7개의 추가 클라우드 통제 항목이 포함되어 있었으며, 여기에는 가상 머신 강화 및 계약 종료 시 고객 자산 반환 등과 같은 사항이 포함되었습니다. 2026년판에서는 클라우드 관련 추가 항목을 4개로 축소했는데, 이는 공급자와 고객 간의 기본 공동 책임 분담, 공급자의 공급망에 속한 브로커나 감사인 등 관련 클라우드 서비스 파트너의 역할 및 책임에 대한 합의, 가상 컴퓨팅 환경 내 분리, 그리고 무단 클라우드 사용의 탐지 및 방지입니다.
나머지 클라우드 지침의 대부분은 이제 관련 ISO/IEC 27002:2022 통제 항목 자체에 중첩된 클라우드 전용 참고 사항으로 구성되어 있습니다.
이전과 마찬가지로, 이에 대한 별도의 인증서는 없습니다. 이는 클라우드 서비스가 적용 범위에 포함된 ISO/IEC 27001 인증의 일환으로 심사됩니다. 귀사의 규정 준수 문서에 여전히 CLD 번호로 표기된 기존의 7가지 통제 항목이 언급되어 있다면, 이는 더 이상 사용되지 않는 구조를 참조하고 있는 것이므로, 2026년판을 기준으로 심사하는 심사관이 이를 문제 삼을 가능성이 높습니다.
이는 클라우드 제공업체가 기업 고객에게 관리 성숙도를 입증하는 데 가장 유용하며, 클라우드 계약 관계에서 직무 분담을 단순한 영업 대화보다 더 구체적인 형태로 명시하고자 하는 고객에게도 유용합니다.
2. SOC 2
SOC 2는 AICPA에서 제정한 것으로, 이 목록에 포함된 대부분의 항목과는 운영 방식이 다릅니다. 면허를 보유한 공인회계사(CPA) 법인이 귀사의 내부 통제 체계를 검토한 후 의견 보고서를 발행합니다. 공급업체의 홈페이지에 어떤 내용이 나와 있든 간에, 공식적인 ‘SOC 2 인증’ 마크는 존재하지 않습니다.
이 심사는 다음을 기준으로 진행됩니다. 2017년 신뢰 서비스 기준에 따라 진행되며, AICPA는 새로운 기술과 위협에 대응하여 지침을 최신 상태로 유지하기 위해 2022년에 중점 사항을 개정하여 발표했습니다. 기본 기준 자체는 2017년 이후 변경되지 않았습니다. 기준은 보안, 가용성, 처리 무결성, 기밀성, 개인정보 보호의 다섯 가지 범주로 나뉩니다. 보안은 모든 SOC 2 보고서에 필수적으로 포함되어야 하며, 나머지 항목은 고객에게 약속한 내용에 따라 추가하게 됩니다.
제1종 보고서는 특정 시점의 통제 설계를 설명합니다. 제2종 보고서는 일반적으로 3개월에서 12개월 사이의 일정 기간 동안의 운영 효율성을 설명하며, 기업 구매 담당자들이 주로 요청하는 것은 바로 이 보고서입니다. SOC 2 요건을 충족하고 유지하기 위한 가이드 SOC 2 규정 준수 가이드에서는 가동 시간 약속과 패치 적용 기간 사이의 상충 관계를 다루고 있습니다.
3. GDPR
GDPR, 정식 명칭은 규정 (EU) 2016/679이며, EU 내에 설립된 조직은 물론, EU 내 거주자에게 상품이나 서비스를 제공하거나 이들의 행동을 모니터링하는 EU 외부의 조직에도 적용됩니다. 특히 클라우드의 경우, 데이터 관리자와 처리자의 구분이 가장 중요합니다. 데이터 처리 계약(DPA)을 체결해야 하며, 유럽경제지역(EEA) 외부로의 데이터 전송에 대한 문서화된 보호 조치를 마련해야 하고, 통제자가 보고 대상인 개인정보 침해 사실을 인지한 후 지체 없이, 가능한 경우 72시간 이내에 감독 당국에 통지할 수 있는 절차를 마련해야 합니다. 처리자는 이에 따라 통제자에게 지체 없이 이를 알려야 합니다.
최대 벌금은 2,000만 유로 또는 전 세계 연간 매출액의 4%중 더 높은 금액입니다.
4. HIPAA
다음 건강보험 이동성 및 책임법(HIPAA) 는 미국 내 건강 정보 보호를 위한 기본 기준을 제시하며, HHS(보건복지부) 민권국에서 집행합니다. GDPR과 마찬가지로, 이는 자발적인 지침이 아닌 법적 규범입니다. 이 법은 적용 대상 기관(의료 서비스 제공자, 건강 보험사, 의료 정보 중개 기관) 및 해당 기관의 업무 협력사에 적용됩니다. 규제 대상 기관을 대신하여 전자 보호 건강 정보(ePHI)를 생성, 수신, 유지 관리 또는 전송하는 클라우드 제공업체는, 해당 데이터를 직접 열람하지 않더라도 사업 협력자로 간주됩니다.
‘업무 제휴 계약(BAA)’은 각 당사자의 책임을 명시하며, 계약상 서비스 제공자가 전자 건강 정보(ePHI)를 안전하게 보호할 것을 의무화합니다. 이러한 역할을 수행하는 클라우드 서비스 제공자는 해당 HIPAA 요건을 준수할 직접적인 책임이 있으며, 이러한 책임은 BAA 여부와 무관합니다.
기술적 요건은 보안 규칙에 명시되어 있습니다: 접근 통제, 감사 통제, 무결성, 전송 보안, 그리고 위험 분석이 바로 그것입니다. 제안된 개정안은 현재의 “필수” 및 “선택적” 사양 간의 구분을 폐지하고, 극히 제한된 예외를 제외하고는 암호화, 다단계 인증, 문서화된 기술 자산 목록 작성을 의무화할 것입니다. 2026년 10월 현재, 해당 최종 규칙은 아직 발표되지 않았습니다. HHS의 규제 일정에 따르면, 당초 목표였던 2026년 5월이 지나간 후, 현재 목표 시한은 2027년 7월로 설정되어 있습니다.
5. PCI DSS
The PCI 보안 표준 위원회 에서 이 문서를 발간하며, 현재 버전은 v4.0.1입니다. 명칭에는 “표준”이라고 되어 있지만, 실제 적용은 계약에 따라 이루어집니다. 정부 규제 기관이 아닌, 가맹점 결제 대행 은행과 카드 브랜드 측에서 이를 집행합니다.
여기서 중요한 기한은 이미 지났습니다. 버전 4.0에서는 새로운 요구사항이 대거 도입되었으며, 향후 적용 예정이었던 51개 항목은 2025년 3월 31일부터 의무화되었습니다. 현재 이 모든 항목이 시행 중이며, 더 이상 유예 기간을 이용할 수 없습니다.
PCI DSS는 또한 이 목록에 포함된 규정 중에서도 가장 명확한 패치 적용 의무를 규정하고 있습니다. 요구사항 6.3.3에 따르면, 중대한 취약점에 대한 패치는 출시 후 1개월 이내에 적용해야 하며, 그 외의 모든 해당 패치는 해당 기관이 자체 위험 등급에 따라 정한 일정에 따라 적용해야 합니다. 원래 v4.0 버전의 규정에서는 이 1개월 적용 기간을 잠시 확대하여 심각도가 높은 패치까지 포함시켰습니다. 그러나 위원회는 v4.0.1에서 이를 다시 ‘중요’ 취약점만 적용 대상으로 제한했으며, 이것이 현재 적용되는 더 엄격한 요구사항입니다. 요구사항 11.3.1은 별도로, 최소 3개월에 한 번씩 그리고 중대한 변경이 발생한 후에는 내부 취약점 스캔을 실시할 것을 요구하고 있습니다.
6. ISO/IEC 27001 (2022년판)
ISO/IEC 27017 및 27018과는 달리, ISO/IEC 27001은 는 실질적이고 독립적인 인증서를 발급해 줍니다. 공인된 인증 기관이 귀사의 정보 보안 관리 시스템을 심사하고 3년 주기로 인증서를 발급하며, 그 사이에는 매년 실시되는 유지 심사를 통해 인증의 유효성을 지속적으로 검증합니다.
2022년 개정판에서는 부록 A를 대폭 개편하여 114개 통제 항목을 93개로 통합하고, 이를 4가지 주제로 분류했습니다. 이러한 구조 조정과 함께 위협 인텔리전스, 클라우드 서비스 정보 보안, 데이터 유출 방지 등 11개의 완전히 새로운 통제 항목이 추가되었습니다.
2013년판에서 전환할 수 있는 기간은 2025년 10월 31일에 종료되었으며, 여전히 2013년판에 따라 발급된 인증서는 더 이상 유효하지 않습니다. 귀 조직이 전환 기한을 놓친 경우, 간소화된 전환 심사가 아닌 새로운 초기 인증 심사를 받아야 합니다.
7. ISO/IEC 27018 (2025년판)
ISO/IEC 27017과 동일한 ISO/IEC 위원회에서 관리하는 이 표준은 27017과 유사한 구조를 가지고 있습니다. 이 표준 자체로는 독립적인 인증을 받을 수 없습니다. 이는 ISO/IEC 27001 기반의 정보보안관리시스템(ISMS)을 보완하는 지침이며, 일부 인증 기관은 27001 감사와 병행하여 이 표준에 따라 평가를 수행하기도 합니다. 현재 제3판이 2025년 8월에 발간되어 2019년 버전을 대체했으며, 통제 항목이 ISO/IEC 27002:2022에 맞춰 재조정되고 새로운 부록 B가 추가되었습니다.
27017이 클라우드 보안을 광범위하게 다루는 반면, 반면 27018 는 한 가지 구체적인 주제를 심도 있게 다룹니다. 바로 서비스 제공자가 PII 처리자 역할을 수행하는 퍼블릭 클라우드 환경에서 개인 식별 정보(PII)를 보호하는 것입니다. 이에 따라 동의, 처리 목적의 제한, 하위 처리자에 대한 공개, 데이터 처리 및 저장 위치에 대한 투명성, 그리고 관계 종료 시 데이터 삭제 등이 적용 범위에 포함됩니다.
이는 GDPR이 규정하는 처리자의 의무에 명확하게 부합하는, 공인된 개인정보 보호 통제 체계를 원하는 퍼블릭 클라우드 제공업체에게 안성맞춤입니다.
8. CSA STAR 및 클라우드 통제 매트릭스
클라우드 보안 연합(Cloud Security Alliance)은 이 두 가지를 모두 관리하고 있으며, 이 둘은 혼동되기 쉽습니다. ‘클라우드 통제 매트릭스(Cloud Controls Matrix)’는 통제 프레임워크 그 자체입니다. ‘STAR’는 이를 기반으로 구축된 보증 프로그램입니다. CCM v4.1 은 2026년 1월 말에 11개의 새로운 통제 항목을 추가하여 총 207개 항목으로 확대되었으며, 여전히 동일한 17개 영역을 다루고 있습니다.
STAR는 세 가지 단계로 운영됩니다. 1단계는 CAIQ 설문지를 기반으로 한 무료 자가 평가로, 누구나 열람할 수 있는 공개 등록부에 게시됩니다. 2단계는 독립적인 제3자 평가를 추가한 것으로, 대개 이미 진행 중인 ISO 27001 또는 SOC 2 인증 작업과 병행하여 수행됩니다. CSA는 또한 지속적인 감사를 기반으로 한 3단계를 설명하고 있지만, 실제로 접하게 될 등록부 목록은 1단계와 2단계입니다.
실질적인 가치는 레지스트리 자체에 있습니다. STAR에 정보를 공개한 클라우드 공급업체를 평가하고 있다면, 해당 업체의 CAIQ 답변은 공개되어 있으며, 다른 증거 자료와 대조해 확인할 수 있을 만큼 구체적입니다. 다만 레벨 1 답변은 자체 보고된 내용이라는 점을 명심하시기 바랍니다.
9. NIST SP 800-53 (버전 5.2.0)
NIST는 이 문서를 인증서가 아닌 통제 카탈로그로 발간하며, 이는 FedRAMP의 기준선과 수많은 민간 부문 통제 매핑의 기초 자료로 활용되고 있습니다.
5.2.0 릴리스가 2025년 8월 27일에 출시되었으며, 패치 관리를 담당하는 모든 사용자는 이 내용을 숙지해야 합니다. 소프트웨어 업데이트 보안에 관한 연방 행정 명령에 따라 발표된 이번 릴리스에는 시스템 문제 및 장애에 대한 근본 원인 분석 기능이 강화되었으며, 여기에는 업데이트 실패(SI-02(07)), 로깅 구문 개선(SA-15(13)), 그리고 새로운 사이버 복원력 설계 통제(SA-24)가 포함됩니다.
이번 업데이트는 패치 파이프라인 자체가 보안 조치가 필요한 공격 표면으로 간주하며, 단순히 해당 파이프라인이 해결하기 위해 존재하는 취약점만을 대상으로 하지 않습니다.
10. NIST 사이버보안 프레임워크 2.0
NIST는 이 지침도 발간하고 있으며, 2024년 2월에 2.0 버전이 나왔습니다. 이는 자발적인 지침으로, 인증 절차가 없으며 충족해야 할 감사 기준도 없습니다.
CSF 2.0 기존의 5가지 기능인 ‘식별(Identify)’, ‘보호(Protect)’, ‘탐지(Detect)’, ‘대응(Respond)’, ‘복구(Recover)’에 더해 여섯 번째 기능인 ‘관리(Govern)’가 추가되었습니다. 또한 버전 1.1을 형성했던 핵심 인프라 중심의 범위를 확대하여, 이제는 규모나 업종을 불문하고 모든 조직을 대상으로 합니다.
이를 보안 프로그램의 조직도라고 생각하면 됩니다. 그 아래에는 800-53, CIS, CCM의 세부 통제 항목들이 매핑되어 있습니다. CSF는 무엇을 구성해야 하는지 알려주는 데는 약하지만, 책임자를 지정하는 것을 깜빡한 부분이 무엇인지 파악하는 데는 강점을 보입니다.
11. FedRAMP
GSA 산하 FedRAMP PMO가 운영하며, FedRAMP는 는 미국 연방 기관이 사용할 수 있는 클라우드 서비스를 승인하며, 2026년에는 수년 만에 가장 큰 규모의 개편이 이루어졌습니다.
FedRAMP는 2026년 통합 규정 을 6월 말에 발표했습니다. 이 규정은 2026년 7월 4일에 발효되어 조기 도입 단계가 시작되었으며, FedRAMP 20x는 향후 Rev5를 대체할 예정입니다. 구조와 함께 용어도 변경되었습니다. “승인(Authorization)”은 “FedRAMP 인증(FedRAMP Certification)”으로 변경되었고, 영향 수준은 A~D 등급의 인증으로 대체되었으며, 제공업체는 더 이상 조치 계획 및 이정표(POA&M)를 유지하지 않습니다. 대신 취약점 기록과 허용된 취약점 목록을 관리하며, 기관은 기관 자체의 조치 및 위험 결정에 대해 여전히 자체 POA&M을 작성할 수 있습니다.
어떤 날짜가 중요한지는 귀하의 상황에 따라 다릅니다. 이미 Rev5 인증을 보유하고 계신 경우, 통합 규칙(Consolidated Rules)은 2027년 1월 1일부터 의무적으로 적용되지만, 일부 규칙 세트에는 별도의 발효일과 유예 기간이 적용되며, 이러한 유예 기간 중 마지막 기간은 2028년 2월 1일에 종료됩니다. 아직 Rev5 인증 신청을 계획 중이라면, FedRAMP는 2027년 6월 11일부로 신규 신청을 접수하지 않으며, 그 이후에는 20x 인증이 유일한 경로가 됩니다. 만약 귀하의 문서에 여전히 “FedRAMP Moderate ATO”라고 명시되어 있다면, 이는 Rev5 용어이며, 귀하에게 적용되는 마감일은 통합 규칙이 의무화되는 2027년 1월 1일입니다. 시간이 남아 있기는 하지만, 그리 많지는 않습니다.
새로운 규정이 그 적용 범위를 좁혔음에도 불구하고, FIPS 인증 암호화는 여전히 중요합니다. FedRAMP는 이제 민감한 데이터를 보호하기 위해 FIPS 140 암호화를 요구하며, 공급업체가 이를 어디에 사용하는지 문서화하도록 하여 각 기관이 자체 시스템에 적합한지 판단할 수 있도록 하고 있습니다. AlmaLinux에서는, TuxCare 엔터프라이즈 지원 는 선별된 마이너 버전에 대해 ‘확장 보안 업데이트(Extended Security Updates)’를 통해 전체 FIPS 패키지 세트(커널, OpenSSL, libgcrypt, NSS, GnuTLS)에 대한 FIPS 준수 업데이트를 제공합니다. AlmaLinux 9.2와 9.6은 모두 5개 모듈 모두에 대해 유효한 CMVP 인증서를 보유하고 있으며, 가장 최근 인증서는 2026년 8월에 발급되었습니다.
12. NIS2 지침
NIS2, 공식 명칭은 (EU) 2022/2555 지침인 NIS2는 규정과는 달리 지침의 성격을 띠고 있어 그 운영 방식이 다릅니다. 이 지침은 회원국들에게 법적 구속력을 갖지만, 기업에 대한 의무는 각국이 이를 국내법으로 이관한 후에야 발생하며, 이러한 이관 과정은 유럽연합 전역에서 고르지 않게 진행되고 있습니다.
이 법의 국내법 전환 마감일은 2024년 10월 17일이었다. 2026년 7월, 유럽집행위원회는 아일랜드, 스페인, 프랑스, 네덜란드가 법의 완전한 국내법 전환을 통보하지 않았다는 이유로 이들 국가를 유럽연합 사법재판소에 제소하고, 재판소에 재정적 제재를 부과해 줄 것을 요청했다. 네덜란드는 2026년 8월 15일에 ‘사이버보안법’을 시행했으며, 9월 중순 현재 아일랜드, 스페인, 프랑스는 여전히 관련 법안 마련을 진행 중이었다. NIS2는 지침이므로 민간 기관에 대한 의무는 각국의 국내 이행법에 따라 달라지므로, 일률적인 직접적 효력이 있다고 가정하기보다는 해당 국내 법률을 확인해야 한다. NIS2는 회원국들이 국내법에 따라 경영진에게 책임을 지도록 요구하며, 각국의 규정은 핵심 기관에 대해 최소 1,000만 유로 또는 전 세계 연간 매출액의 2% 중 더 높은 금액을 벌금으로 부과할 수 있도록 해야 한다.
NIS2는 클라우드 컴퓨팅 제공업체, 데이터 센터 서비스, 관리형 보안 서비스 제공업체 등 18개 분야의 사업체를 대상으로 합니다.
13. DORA
『 디지털 운영 복원력법, 즉 규정 (EU) 2022/2554는 2023년 1월에 발효되었으며, 2025년 1월 17일부터 전면적으로 적용되기 시작했다. 유럽 감독 당국이 이 법의 이행을 조정한다.
DORA는 EU 전역의 금융 기관에 직접 적용되며, ICT 위험 관리, 사고 보고, 디지털 운영 복원력 테스트, ICT 제3자 위험 관리, 정보 공유라는 다섯 가지 핵심 축을 기반으로 구성되어 있습니다.
제3자 부문은 클라우드 제공업체들이 간과하기 쉬운 부분입니다. 금융 기관들은 DORA의 요구 사항을 자사의 ICT 계약에 반영해야 하며, 핵심 ICT 제3자 제공업체로 지정된 업체는 유럽금융감독청(ESAs)에서 선임된 주 감독관의 직접적인 감독을 받게 됩니다. 즉, 비록 해당 업체가 금융 기관은 아니더라도 EU 은행에 인프라를 판매하는 경우 DORA의 적용 범위에 포함될 수 있습니다.
14. CIS 벤치마크 및 CIS 통제 사항 v8.1
인터넷 보안 센터(Center for Internet Security)는 이곳에서 두 가지 관련 자료를 공개하고 있습니다. 하나는 우선순위가 지정된 보안 조치 모음인 ‘컨트롤(Controls)’이고, 다른 하나는 플랫폼별 구성 기준인 ‘벤치마크(Benchmarks)’입니다. 이 두 가지 모두 전통적인 의미에서 인증을 받을 수 있는 것은 아닙니다.
CIS Controls v8.1는 2024년 6월에 출시되었으며, 18개의 우선순위가 지정된 통제 항목을 위험, 자원, 복잡성을 기준으로 세 가지 구현 그룹으로 분류하여, 소규모 팀과 대기업이 동일한 초기 기대치를 충족해야 하는 부담을 덜어줍니다. CIS 벤치마크 는 구성 수준에 해당하는 것으로, AWS Foundations, Azure Foundations, GCP, Kubernetes 및 주요 리눅스 배포판을 포함합니다.
벤치마크는 표준이 더 이상 추상적인 개념에 그치지 않고, 어떤 설정을 변경해야 하는지 구체적으로 알려주는 지점입니다. 많은 클라우드 보안 상태 관리 도구가 CIS 벤치마크 검사 기능을 기본으로 제공하므로, 이 목록에 포함된 도구 중 가장 쉽게 시작할 수 있는 방법 중 하나입니다.
AlmaLinux의 경우, TuxCare 엔터프라이즈 지원 에는 CIS 및 STIG 제어 항목을 PCI DSS 및 ISO 27001과 같은 규정 준수 프레임워크에 매핑하는 보안 강화 지원이 포함됩니다.
클라우드 보안을 위한 모범 사례
표준은 무엇을 입증해야 하는지를 알려줍니다. 이 다섯 가지 실천 방법은 팀이 실제로 그 증거를 제시하는 방식입니다.
정기 보안 평가
감사관이 방문할 때만 평가를 실시하는 것이 아니라, 정해진 주기에 따라 평가를 실시하십시오. 주기는 표준에 따라 다르며, 일부는 연간 주기를 명시하고 있는 반면, 다른 일부는 고정된 주기가 없는 위험 기반 방식입니다. PCI DSS 요구사항 12.5.2는 귀하가 선택한 주기에 더해 연간 범위 확인 절차를 추가로 규정하고 있습니다.
경제적 관점에서 볼 때 이를 계속 유지하는 것이 유리합니다. IBM의 ‘2026년 데이터 유출 비용 보고서’에 따르면 에 따르면, 전 세계 평균 데이터 유출 사고 비용은 499만 달러로, 전년 대비 12% 증가하여 일시적인 감소세를 보였던 전년의 추세를 뒤집고 새로운 기록을 세웠습니다.
범위 이탈은 주의 깊게 살펴봐야 할 오류 유형입니다. 40명으로 구성된 SaaS 팀이 마이그레이션을 위해 스테이징 환경을 구축한 뒤, 이를 해체하는 것을 깜빡하고 수개월 동안 평가 대상 범위 밖에서 방치해 둔 상황을 상상해 보세요.
평가 결과 아무런 문제도 발견되지 않는다면, 평가 범위가 너무 좁게 설정된 것일 가능성이 높습니다. 매 분기마다 똑같은 세 가지 문제만 발견된다면, 문제는 탐지 과정이 아니라 시정 조치의 책임 소재에 있습니다.
취약점 스캐닝
외부 스캔 외에도 환경 내부에서 인증된 스캔을 실행하십시오. 인증되지 않은 외부 스캔은 실행 중인 워크로드의 패키지 수준 취약점을 놓치기 쉬운데, 실제로 악용될 수 있는 취약점의 상당수가 바로 이곳에 존재합니다.
최소 검사 주기는 표준에 따라 크게 다릅니다. PCI DSS는 3개월마다, 그리고 중대한 변경이 발생한 후에는 내부 및 외부 스캔을 실시할 것을 요구하며, 필수 외부 스캔은 승인된 스캔 업체(Approved Scanning Vendor)를 통해 수행되어야 합니다. DORA의 기술 표준은 중요 또는 핵심 기능을 지원하는 ICT 자산에 대해 최소 주 1회 자동 취약점 스캔을 실시하고, 해당 기능을 뒷받침하는 시스템에 대해 연 1회 테스트를 수행하며, 규제 당국이 지정한 기관에 대해서는 최소 3년마다 위협 기반 침투 테스트를 실시할 것을 요구합니다. 제안된 HIPAA 개정안은 최소 6개월마다 자동 스캔을, 그리고 최소 연 1회 침투 테스트를 실시하도록 요구할 것입니다. CIS Controls v8.1은 내부 자산에 대해서는 최소 분기별(Safeguard 7.5), 외부에 노출된 자산에 대해서는 최소 월별(Safeguard 7.6) 자동 스캔을 요구합니다. NIS2는 위험 기반 접근 방식을 유지하며 구체적인 사항은 각 회원국에 맡기고 있습니다.
조사 결과를 다음과 대조해 보십시오. CISA ‘악용된 것으로 알려진 취약점’ 목록 와 대조하여 확인하십시오. CVSS 점수만으로는, 실제로 악용되고 있는 7.5 점의 취약점이 알려진 악용 사례가 없는 이론상의 9.8 점 취약점들 속에 묻혀 버릴 수 있습니다.
위의 업데이트 주기 규칙은 스캐너가 이미 수정된 사항을 정확하게 보고한다고 가정하지만, 리눅스에서는 이러한 가정이 종종 성립하지 않습니다. 배포판들은 업스트림 버전 번호를 변경하지 않고 보안 수정 사항을 백포트하며, 메모리에서 적용된 재부팅이 필요 없는 패치는 패키지 버전 확인 시 전혀 표시되지 않을 수도 있습니다. TuxCare Radar 는 재부팅이 필요 없는 패치나 단순한 버전 확인으로는 놓치기 쉬운 ELS 적용 수정 사항을 포함하여 실제 패치 상태를 확인하므로, 스캔 주기가 스캐너가 표시하는 내용과 패치 로그에 기록된 내용을 수동으로 대조하는 과정으로 변질되는 것을 방지합니다.
강력한 액세스 제어
적용 다단계 인증 콘솔에 접근 권한이 있는 모든 사용자 계정에 대해, 서비스 소유자나 계약자를 예외로 두지 않고 다중 인증을 적용해야 합니다. PCI DSS v4.x는 관리자뿐만 아니라 카드 소지자 데이터 환경에 접근하는 모든 사용자에게 다중 인증을 확대 적용했으며, 피싱 방지 인증 방식을 사용하는 계정에 한해 제한적인 예외를 두었습니다. 또한 제안된 HIPAA 개정안도 이와 같은 방향으로 나아가고 있습니다.
MFA 외에도, 최소 권한 원칙에 기반한 역할 기반 접근 권한을 기본 설정으로 적용하고, 최소 분기별로 이를 검토하십시오. 사람과 기계의 신원을 분리하고, CI 파이프라인 내에 공유 서비스 계정 자격 증명이 존재하지 않도록 하십시오. 제공업체에서 지원하는 경우, 장기 유효한 API 키보다는 단기 유효한 자격 증명을 선택하십시오. 또한, 감사관이 정기적으로 이를 표본 조사하므로, 입사·전근·퇴사 절차를 문서화하십시오.
데이터 암호화
저장 중인 데이터와 전송 중인 데이터를 암호화하는 것은 기본적인 요건입니다. 실제로 감사에서 문제가 되는 부분은 바로 키 관리입니다. 즉, 누가 키를 보유하고 있는지, 키를 얼마나 자주 교체하는지, 그리고 서비스 제공자가 어떤 데이터를 복호화할 수 있고 어떤 데이터는 복호화할 수 없는지 정확히 입증할 수 있는지 여부입니다.
규제 대상 워크로드의 경우, 구현 방식은 알고리즘 선택 자체만큼이나 중요합니다. 미국 연방 시스템은 일반적으로 승인된 암호화 기술이 의무화되는 모든 곳에서 FIPS 140-3 인증을 받은 암호화 모듈을 요구하며, 상업 계약에서도 이를 요구하는 경우가 점점 늘고 있습니다. TLS 1.2는 최소 기준이며, 스택이 지원하는 곳에서는 TLS 1.3을 목표로 삼아야 합니다.
주의 사항: 서비스 제공자가 관리하는 키를 사용한 저장 중 암호화는 많은 규정 준수 요건을 충족시키지만, 실제로 보호하는 대상은 디스크 도난이나 부적절하게 폐기된 저장 매체와 같은 저장 계층의 노출입니다. 이는 암호 해독 권한이 있는 사용자 계정 내부의 인증 정보가 유출된 경우에는 아무런 효과가 없습니다. 감사관들은 이 차이점을 거의 지적하지 않지만, 공격자들은 이를 일상적으로 악용합니다.
정기 패치 및 업데이트
대부분의 클라우드 규정 준수 프로그램은 바로 이 지점에서 조용히 무너집니다. 통제 조치는 문서상으로는 간단해 보이지만 실제로 운영하기는 어렵습니다. 운영 환경의 커널에 패치를 적용하려면 대개 재부팅이 필요하고, 재부팅을 하려면 해당 시스템의 가동 시간에 의존하는 모든 관계자와 유지보수 시간을 조율해야 하기 때문입니다.
이 시계는 여러 표준에 걸쳐 명확하게 규정되어 있습니다:
| 표준 | 패치 요구 사항 |
| PCI DSS v4.0.1 | 출시 후 1개월 이내에 중요 패치를 적용하고, 그 외 적용 가능한 패치는 해당 기관이 정의한 위험 기반의 일정에 따라 적용해야 합니다(요구사항 6.3.3). |
| NIST SP 800-53 | 조직이 정한 기한 내에 결함 시정 (SI-02) |
| CIS Controls v8.1 | 운영 체제 및 애플리케이션 패치 관리 자동화, 매월 또는 그보다 더 자주 수행 (Safeguards 7.3 및 7.4) |
| NIS2 / DORA | 일률적인 기한은 없으며, 시정 조치의 시기는 각 체제의 위험 및 취약점 관리 요건에 따라 결정됩니다(DORA의 스캔 및 테스트 주기에 대해서는 위의 ‘취약점 스캔’ 항목 참조). |
| HIPAA (안) | ‘매우 높은 위험’ 등급 패치는 15일 이내, ‘높은 위험’ 등급 패치는 30일 이내에 적용하며, 그 외 패치는 정책에 정의된 일정에 따라 적용합니다. |
30일이라는 기간은 넉넉해 보이지만, 실제로 필요한 단계들—우선순위 분류, 테스트, 일정 수립, 통보, 재부팅, 검증, 문서화—을 하나하나 따져보면 이야기가 달라집니다. 가동 시간 SLA를 준수해야 하는 수백 대의 호스트로 구성된 인프라에서는, 패치가 실제 운영 환경에 적용되기도 전에 한 달의 대부분이 소요될 수 있습니다.
최종 생각
먼저 법적 의무에 따라 표준을 선정하고, 그다음 구매자의 요구 사항에 따라 선정한 뒤 거기서 멈추세요. 경쟁사의 신뢰 페이지에 ISO 27001, SOC 2, CSA STAR가 모두 나열되어 있다는 이유만으로 이 세 가지를 한꺼번에 도입하는 것은, 소규모 보안 팀이 통제 조치 대신 문서 작업에만 1년을 허비하게 만드는 지름길입니다.
어떤 기준이 적용되든 상관없이 한 가지 사실은 변함이 없습니다. 거의 모든 기준에서 알려진 취약점을 찾아서 수정하고, 요청 시 제시할 수 있는 증거를 확보할 것을 요구합니다. 인증 유형은 다양하고, 시행 방식도 제각각입니다. 하지만 이러한 프로그램 대부분에서, 패치 작업이 바로 그 증거를 예정대로 제시할 수 있는지, 아니면 제때 처리하지 못하는지가 결정되는 관건입니다.
끝없는 라이프사이클 지원 는 공급업체의 지원이 종료된 후에도 수명 종료된 운영 체제, 언어 런타임 및 라이브러리에 보안 업데이트를 지속적으로 제공하므로, 지원이 중단된 구성 요소가 지속적인 규정 준수 취약점으로 남는 대신 계속해서 수정 패치를 받을 수 있습니다. 클라우드 워크로드가 불러오는 오픈 소스 종속성의 경우, SecureChain 는 팀에 JavaScript, Python, Java, Go, Rust 및 PHP 패키지를 위한 선별된 비공개 레지스트리를 제공하며, 이는 ISO/IEC 27017 및 CCM v4.1에서 규정하는 공급망 관리 방식을 지원합니다. TuxCare Enterprise Support 는 연방 정부 및 기타 규제 환경에서 흔히 요구하는 FIPS 인증 암호화 및 규정 준수 강화 조치를 포괄합니다. 또한 KernelCare 는 재부팅 없이 커널 패치를 적용하므로, PCI DSS 및 유사한 표준에서 정한 기한을 준수하는 데 유지보수 시간대 승인이 필수적이지 않습니다. 다른 패치와 마찬가지로 테스트, 검증 및 문서화 과정은 여전히 진행되지만, 재부팅 단계는 일정에 포함되지 않습니다.
이러한 표준 중 어떤 것이 귀사의 환경에 적용되는지, 또는 귀사의 규정 준수 프로그램에서 실제로 어떤 부분에서 증거가 부족한지 궁금하신가요? TuxCare 보안 전문가와 상담해 보세요.




