요약. NIS2 Article 21(2)(d)는 공급망 리스크를 구매 부서의 각주가 아닌 이사회 수준의 문제로 만듭니다. 지침은 셀프호스팅을 의무화하지 않습니다. 그러나 데이터 경로에 무엇이 있으며, 그 벤더 중 하나가 최악의 하루를 맞이했을 때 여러분에게 어떤 일이 발생하는지를 묻습니다. 셀프호스팅 인프라는 대부분의 SaaS 데이터 경로에서 4개 레이어 중 3개를 제거합니다. 4개 전부를 제거하지는 않으며, 그렇다고 주장하는 것은 감사인 앞에서 CISO를 곤경에 빠뜨리는 마케팅 수법입니다.
- 지침 원문과 ENISA 가이던스를 평이한 언어로 해설합니다.
- 대부분의 팀이 그리지 않는 SaaS 4계층 데이터 경로를 설명합니다.
- Rediacc의 2도구 모델이 벤더 등록부에서 제거하는 것과 남기는 것을 정리합니다.
- “NIS2 준비 완료”를 주장하는 모든 벤더에 적용할 6개 질문 구매 체크리스트를 제공합니다.
2020년 7월, Blackbaud는 몸값을 지불하고 이후에 세상에 알렸습니다. 13,000개 이상의 고객 조직에 사후 통보를 보냈고, 7개 사법관할권에서 집단소송을 방어해야 했으며, 결국 주 검찰총장 합의금 $49.5백만과 허위 공시에 대한 SEC 벌금 $3백만을 납부했습니다. 그 13,000개 조직 모두 Blackbaud와 데이터 처리 계약(DPA)을 체결한 상태였습니다. 대부분이 Blackbaud의 SOC 2 보고서를 검토했습니다. 많은 조직이 Blackbaud를 벤더 리스크 등록부에 올려두고 있었으며, 티어 등급, 갱신일, 담당자 이름까지 명시했습니다.
그 어느 것도 연쇄 침해를 막지 못했습니다. 데이터는 Blackbaud 쪽 경계에 있었습니다. 그들의 백업 환경이 침해당하자 모든 고객 조직이 동시에 침해당했습니다.
NIS2 Article 21(2)(d)는 “벤더를 감사했는가”보다 더 어려운 질문을 던집니다. 데이터 경로에 무엇이 있으며, 그 벤더가 최악의 하루를 맞이했을 때 여러분에게 어떤 일이 발생하는지를 묻습니다. 대부분의 팀에게 그 답은 “우리는 그들과 같은 처지이며, 그것을 인식하지 못했다”입니다.
이 글은 2026년에 DPA를 재협상 중인 CISO와 구매 담당자를 위한 것입니다. Article 21(2)(d)의 인증서 관점이 아닌 데이터 경로 관점의 해석입니다. 또한 셀프호스팅 인프라가 해결하지 못하는 것에 대해서도 솔직하게 다룹니다. 왜냐하면 감사인이 묻는 것은 바로 그 공백 영역이며, 마케팅 브로슈어가 건너뛰는 부분이기 때문입니다.
21(2)(d)가 실제로 의무화하는 것
지침의 영문 원문은 다음과 같습니다. 공식 한국어 번역본이 존재하지 않으므로 원문을 그대로 인용합니다:
“Member States shall ensure that essential and important entities take appropriate and proportionate technical, operational and organisational measures to manage the risks posed to the security of network and information systems which those entities use […] and shall include at least the following: […] (d) supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers”
이 문구에서 구매자 입장에서 중요한 두 가지가 있습니다.
첫째, 의무는 벤더가 아닌 여러분에게 있습니다. 벤더의 인증서, SOC 2, ISO 27001은 리스크 평가의 입력값입니다. 대체재가 아닙니다. 벤더가 완벽한 컴플라이언스 자세를 갖추고도 침해당한다면, 규제 당국의 질문은 벤더의 공급자 리스크 관리가 아닌 여러분의 공급자 리스크 관리에 관한 것이 될 것입니다.
둘째, 의무는 계약보다 범위가 넓습니다. ENISA의 2024년 이행 가이던스, 즉 집행 규정 (EU) 2024/2690 부속서 IV는 기대되는 실천 사항을 제시합니다. ICT 공급업체 등록부를 유지하고, 중요도에 따라 분류하며, 운영 및 처리 데이터에 대한 리스크를 각각 평가하고, 정해진 주기로 평가를 갱신하는 것입니다. 부속서 IV는 “공급업체의 공급업체”도 범위 내에 있다고 명시하는데, 이 지점에서 대부분의 팀은 자신들의 벤더 등록부가 진정한 등록부가 아니라 스티커가 붙은 계약 목록임을 깨닫게 됩니다.
구매 측면에서 바라본다면, 실질적인 번역은 이렇습니다. 운영 데이터에 논리적 접근 권한이 있는 모든 벤더는 열거되고, 점수가 매겨지고, 모니터링되며, 교체 가능해야 합니다. “교체 가능”이 대부분의 기존 계약을 깨뜨리는 부분입니다.
대부분의 팀이 그리지 않는 SaaS 4계층 데이터 경로
구매 담당자와 함께 앉아서 백업 벤더 제품이 단 하나의 레코드를 기록할 때 어떤 일이 발생하는지 살펴보십시오. 솔직한 데이터 경로는 상단부터 하단까지 다음과 같습니다:
- 벤더 애플리케이션. 데이터를 수집하고 라우팅 결정을 내리며 비즈니스 로직을 적용하는 코드. 벤더 인프라에서 실행됩니다. 벤더가 유지보수, 패치, 모니터링을 담당합니다.
- 벤더 클라우드. 애플리케이션이 실행되는 하이퍼스케일러 리전 또는 벤더 자체 데이터센터. 스토리지 볼륨, 네트워킹, IAM. 벤더가 하위 처리자 계약을 체결한 하이퍼스케일러인 경우가 많습니다.
- 벤더 키 관리. 벤더 클라우드에서 저장 데이터를 보호하는 암호화 키. 대부분의 SaaS 구성에서 벤더가 이를 보유합니다. “고객 관리 키”는 티어 업그레이드 옵션으로 제공되는 경우가 있으나, 그 경우에도 키는 벤더의 IAM이 호출 가능한 하이퍼스케일러 KMS에 있습니다.
- 벤더 하위 처리자. 벤더가 사용하는 제3자 서비스(CDN, 옵저버빌리티, 결제, 고객 지원 도구)로, 여러분의 데이터 또는 그로부터 파생된 메타데이터를 경유하거나 저장할 수 있습니다.
이 4개 레이어 각각이 Article 21(2)(d) 공급업체 등록부의 한 항목입니다. 각각은 자체 사고 이력, 자체 침해 영향 범위, 자체 계약 협상 공간을 가집니다. SaaS 벤더와 계약을 갱신하면 암묵적으로 4개 전부를 갱신하는 것입니다. SaaS 벤더 계약만이 여러분이 협상할 수 있는 유일한 계약이기 때문입니다.
Blackbaud 사고는 레이어 2(벤더 클라우드) 침해가 레이어 1(벤더 애플리케이션)을 통해 전파되었으며, 레이어 3(벤더 키 관리, 이 경우 침해된 데이터베이스에서 테넌트별 분리가 없는 서버 측 키) 때문에 모든 고객에게 가시화된 사례입니다. Blackbaud의 하위 처리자가 침해 경로는 아니었지만, 고객들은 자신들이 열거하지 않았던 하위 처리자 3곳을 사후에 알게 되었습니다.
Blackbaud, Druva 방식 키 관리, 그리고 연쇄 침해 패턴
Blackbaud의 SEC 공시 서류에서 NIS2 관점으로 중요한 세 가지 세부 사항이 있습니다.
첫째, Blackbaud는 침해 대상이었던 백업 환경을 포함하여 고객 데이터의 암호화 키를 보유하고 있었습니다. 고객 관리 키는 제공되지 않았습니다. 사후 SEC 소송에서 이는 위반이 아닌 통제 공백으로 규정되었는데, Blackbaud의 계약이 이를 허용했기 때문입니다. 동일한 구성에 대한 NIS2의 Article 21(2)(d) 관점은 더 엄격합니다. 고객이 가시성을 갖지 못하는 통제의 리스크를 의미 있게 평가할 수 없기 때문입니다.
둘째, 침해는 라이브 데이터베이스보다 오래된 백업 데이터에 영향을 미쳤습니다. Blackbaud의 주 시스템에서 라이브 데이터가 삭제된 고객 조직들도 백업 환경을 통해 데이터가 노출되었습니다. 이것이 연쇄 침해 패턴입니다. 벤더 침해가 고객이 이미 범위 밖에 있다고 생각한 과거 데이터까지 미치는 것입니다.
셋째, 13,000개 이상의 고객 조직이 침해 통지를 받았습니다. 그 중 상당수는 대응할 운영 역량이 없고, DR 런북도 없으며, 장애 전환을 위한 두 번째 백업 벤더도 없는 소규모 비영리단체와 학교였습니다. 그런 의미에서 벤더의 사고가 그들의 사고가 되었습니다.
Druva 방식의 현대 SaaS 백업의 경우 아키텍처가 일부 영역에서 더 낫습니다(테넌트별 키 분리가 더 보편화되어 있고, BYOK가 상위 티어에서 제공됩니다). 그러나 4계층 데이터 경로는 동일합니다. 벤더 애플리케이션, 벤더 클라우드(일반적으로 AWS), 키 관리(벤더, 고객 KMS의 BYOK, 또는 하이브리드), 하위 처리자. 모든 레이어에서의 침해는 모든 고객에게 동시에 영향을 미칩니다. 모든 고객의 데이터가 경계의 같은 편에 있기 때문입니다.
이것이 구조적 논거입니다. Druva를 비판하는 것이 아닙니다. Druva는 Blackbaud보다 훨씬 잘 운영되고 있습니다. 논거는 SaaS 방식으로 설계된 모든 백업 제품의 구조가, 고객이 의미 있게 이행할 수 없는 21(2)(d) 의무 사항으로서의 레이어 2 및 레이어 3 침해를 만들어낸다는 것입니다.
셀프호스팅은 4개 레이어 중 3개를 제거합니다
Rediacc은 다르게 구축되었습니다. 전체 아키텍처는 아키텍처 페이지에 문서화되어 있으며, 공급망 관련 구조는 SSH로 통신하는 2개의 바이너리입니다:
rdc는 운영자의 워크스테이션에서 실행됩니다.~/.config/rediacc/아래의 평탄한 JSON 구성 파일을 읽고, SSH를 통해 운영자 자신의 머신에 연결하며, 명령을 전달합니다.renet은 운영자 자신의 서버에서 root 권한으로 실행되며, LUKS2 암호화 디스크 이미지, 격리된 Docker 데몬, 리버스 프록시를 관리합니다.
운영자는 백업, 복원, 포크 실행을 위해 Rediacc 회사의 인프라에 로그인하지 않습니다. 데이터 경로에 Rediacc 회사의 클라우드가 없습니다. 레포지터리의 LUKS2 자격증명은 운영자의 로컬 구성 파일(모드 0600)에 저장되며, 서버에는 없고, Rediacc에 전송되지도 않습니다. 데이터 경로는 다음과 같습니다:
- 운영자 워크스테이션.
rdc를 실행합니다. LUKS2 자격증명을 보유합니다. - 운영자 자신의 서버.
renet을 실행합니다. LUKS2 암호화 레포지터리를 보유합니다. - 운영자 자신의 백업 대상. rclone 호환 스토리지(S3, B2, OneDrive, 온프레미스 MinIO). 암호화된 볼륨을 수신합니다.
레이어 4가 없습니다. Rediacc 회사는 실험적인 클라우드 어댑터를 선택하지 않은 운영자에 대한 하위 처리자가 아닙니다. 셀프호스팅 운영자에게 Rediacc 회사와의 관계는 데이터 처리 계약이 아닌 소프트웨어 라이선스입니다.
이것이 데이터 경로 논거이며, 공급업체 등록부 대화에서 먼저 제시해야 할 올바른 논거입니다. SaaS 경쟁사는 고객 관리 키를 제공할 수 있습니다(대부분의 현대 제품이 그렇습니다). SaaS 경쟁사는 “우리는 하위 처리자가 아닙니다”를 제공할 수 없습니다.
데이터 경로 논거가 확립된 다음 두 번째 논점은 키 관리입니다. Rediacc에서는 LUKS2 자격증명이 운영자의 구성 파일에 있습니다, 끝입니다. 운영자가 자격증명을 분실할 경우 Rediacc 회사가 실행할 수 있는 키 에스크로나 복구 서비스가 없습니다. 이것은 또한 제로 지식 구성 저장소의 권장 아키텍처이기도 합니다. 여기서 암호화 키는 패스키 PRF 확장에서 클라이언트 측에서 파생되며, 서버는 불투명한 블롭만 저장합니다. 서버는 SSH 키, LUKS2 자격증명, IP 주소, 또는 평문 구성을 읽을 수 없습니다. 액세스 토큰을 교체해도 서버에 소급 읽기 권한이 부여되지 않습니다.
Article 21(2)(h)(암호화)에서 이것이 중요합니다. Article 21(2)(d)(공급망)에서는 더욱 중요합니다. Rediacc 회사에서 운영자 데이터로 이어지는 마지막 논리적 접근 경로를 제거하기 때문입니다.
셀프호스팅이 제거하지 못하는 것
셀프호스팅은 공급업체 목록을 이동시킵니다, 삭제하지 않습니다. 감사인이 여전히 질문할 세 가지:
1. 공급업체는 여전히 있습니다, 단지 다른 공급업체입니다. 하드웨어 벤더(Hetzner, Hostinger, OVH, 코로케이션, 베어메탈). 하이퍼바이저(KVM, VMware). OS(Debian, Ubuntu, RHEL). 컨테이너 레지스트리(Docker Hub, GHCR, 자체 프라이빗 레지스트리). 서비스가 가져오는 기본 이미지. 각각이 Article 21(2)(d) 항목입니다. 셀프호스팅은 공급업체 목록을 이동시킵니다, 삭제하지 않습니다.
2. Rediacc은 아직 ISO 27001, SOC 2, BSI C5를 보유하지 않습니다. 이것들은 로드맵에 있지, 현재 보유하고 있지 않습니다. 인증서를 게이팅 메커니즘으로 사용하는 구매팀에게 이것은 실질적인 마찰입니다. 방어 가능한 반론은 이 글이 계속 제시해 온 것입니다. 데이터 경로 논거는 그 인증서들이 입증하는 대부분(벤더 클라우드 보안 통제, 벤더 직원 접근 관리, 벤더 하위 처리자 관리)이 범위 밖임을 의미합니다. Rediacc 회사가 데이터 경로에 없기 때문입니다. 그 논거는 신중하고 방어 가능하게 제시되어야 하며, 구매자에게 인증서가 필요할 때 인증서의 대체재로 사용되어서는 안 됩니다.
3. GRC 레이어는 여전히 여러분의 몫입니다. Rediacc은 운영자에게 70개 이상의 이벤트로 구성된 해시 체인 감사 로그(rdc audit verify가 체인을 엔드투엔드로 검증)를 제공합니다. 공급업체 등록부, 통제 프레임워크, 증거 수집 워크플로는 제공하지 않습니다. 그것들은 여전히 Drata, Vanta, OneTrust, 또는 유럽의 신규 진입자에게서 와야 합니다. 동반 게시물 실제 비용 포스트에서 이 상호 보완성의 비용 구조를 자세히 다룹니다.
더 이상 협상하지 않아도 되는 DPA
이를 구체화하기 위해 익명 처리된 실제 구매 대화에서 “이전 vs 이후” 등록부 행을 제시합니다. 구매자는 Annex II “중요 기관”으로 분류된 280명 규모의 독일 제조업체입니다. 백업에 대한 원래 공급업체 등록부 항목은 다음과 같았습니다:
| 필드 | 이전 |
|---|---|
| 벤더 | Acme Backup SaaS |
| 티어 | 중요(Critical) |
| 처리 데이터 | 운영 데이터베이스, 고객 PII, 재무 기록 |
| 하위 처리자 | AWS (eu-central-1), Datadog, Stripe, Zendesk |
| 계약 상태 | DPA 2023년 서명, SCC 첨부, 조치 일정 2025년 1월 최종 검토 |
| 키 관리 | 벤더 관리(현재 티어에서 BYOK 옵션 미제공) |
| 종료 계획 | ”벤더는 계약 종료 후 30일 이내에 CSV 형식으로 데이터 내보내기를 제공하는 데 동의함” |
| 최근 평가 | 2025-Q1, 키 관리 공백 지적, 갱신 시까지 연기 |
Hetzner에서 Rediacc으로 이전 후:
| 필드 | 이후 |
|---|---|
| 벤더 | (1) Rediacc OÜ, 소프트웨어 라이선스; (2) Hetzner, IaaS |
| 티어 | (1) 비중요(데이터 플레인 없음); (2) 중요(데이터 플레인, 단 고객 통제) |
| 처리 데이터 | (1) 없음; (2) 암호화된 볼륨, 고객이 키 보유 |
| 하위 처리자 | (1) 셀프호스팅에 해당 없음; (2) Hetzner 내부 전용, DPA에 명시 |
| 계약 상태 | (1) 소프트웨어 라이선스, DPA 불필요; (2) Hetzner DPA + SCC 기체결 |
| 키 관리 | 고객(LUKS2 자격증명이 운영자 구성에 있으며 서버에 없음) |
| 종료 계획 | ”rclone 호환 대상에서 rdc repo backup pull. 볼륨은 LUKS2 암호화; 운영자가 자격증명 보유.” |
| 최근 평가 | (2) 기존 IaaS 검토로 충당 |
하나 대신 두 개의 등록부 항목입니다. 중요 티어 항목은 IaaS 공급자를 위한 것으로, 구매자는 이미 DPA와 테스트된 종료 계획을 갖추고 있었습니다. IaaS는 대부분의 팀이 관리하는 방법을 알고 있는 관계이기 때문입니다. Rediacc 항목은 비중요 티어입니다. 데이터 처리자가 아닌 소프트웨어 라이선스이기 때문입니다.
이것이 CISO가 스프레드시트에서 조달 비용이 비슷해 보이더라도 데이터 플레인에서 SaaS 의존성을 줄이기를 원하게 되는 구조적 이유입니다. 등록부 항목의 형태가 같지 않습니다.
구매 체크리스트
2026년 영업 사이클에서 “NIS2 준비 완료”를 주장하는 모든 벤더에 대한 여섯 가지 질문:
1. 정지 데이터에 대한 암호화 키가 어디에 있습니까? “저희 HSM에” 또는 “IAM을 통해 호출할 수 있는 고객 KMS에”라고 답한다면, 그 벤더는 키 관리 체인에 있는 것입니다. “귀사의 로컬 구성 파일에 있으며 저희 인프라에는 없습니다”라고 답한다면 그렇지 않습니다.
2. 법적 조건을 무시할 때, 귀사에서 기술적으로 저희 데이터를 읽을 수 있는 사람은 누구입니까? “누가 권한이 있는가”가 아닌 “누가 원한다면, 그리고 감사 로그가 꺼진다면 할 수 있는가”입니다. 그 답이 0이 아니라면, 그것이 내부자 리스크 평가의 대상 집단입니다.
3. 복원이 실제 운영 클론을 대상으로 테스트됩니까, 아니면 합성 테스트 데이터를 대상으로 합니까? Article 21(2)(c) 및 (e)를 함께 읽으면 백업이 실제로 복원되어야 합니다. 합성 데이터만 대상으로 검증하는 벤더는 복구를 검증하는 것이 아니라 백업 파일 무결성을 검증하는 것입니다. (이에 대한 자세한 내용은 지속적 효과성 평가 동반 게시물을 참조하십시오.)
4. 감사 추적이 각 행동 뒤의 행위자 종류, 즉 사람인지 에이전트인지를 기록합니까? AI 에이전트 활동은 가장 빠르게 성장하는 감사 로그 범주입니다. 사람과 에이전트를 구분하지 않는 2026년 감사 로그는 2027년에는 공백으로 보일 것입니다.
5. 메타데이터를 포함하여 저희 데이터에 논리적 접근 권한이 있는 모든 하위 처리자를 나열하십시오. “논리적 접근”이 적절한 표현입니다. “메타데이터 포함 논리적 접근”이 더 나은 표현입니다. 메타데이터 전용 접근이 결제, 옵저버빌리티, 고객 지원 하위 처리자가 일반적으로 갖는 수준이며, 페이로드가 암호화되어 있어도 민감한 구조를 누출하기에 충분하기 때문입니다.
6. 2027년에 비EU 구매자에게 인수될 경우 종료 계획은 무엇입니까? GDPR의 적정성 프레임워크, 클라우드법, FISA 702는 모두 가변적입니다. 오늘의 벤더 데이터 거주 주장은 3년 후의 보장이 아닙니다. 구매자의 질문은 벤더 소유권이 변경될 경우 데이터 경로에 어떤 일이 발생하는가입니다.
6개 중 6개를 깔끔하게 답하는 벤더는 드뭅니다. 6개 중 4개를 답하고 나머지 2개를 공개적으로 인정하는 벤더가 6개 모두에 자신 있게 답하는 벤더보다 신뢰할 수 있습니다. 신뢰성의 신호는 해결되지 않은 것을 명명할 의지입니다.
다음 갱신 주기를 위한 시사점
향후 12개월 내에 백업 또는 DR 갱신을 앞두고 있으며 Article 21(2)(d)가 구매 스코어카드에 있다면, 세 가지 구체적인 조치:
- 현재 벤더의 4계층 데이터 경로를 화이트보드에 그리십시오. 세 번째 하위 처리자를 명명할 수 없다면, NIS2 이전부터 존재하던 등록부 완전성 문제가 있는 것이며 갱신이 이를 해결할 적절한 시점입니다.
- 현재 벤더에 대해 위의 6개 질문 체크리스트를 적용하십시오. 답변을 DPO와 감사인에게 보내고 공백이 수용되는지 확인하십시오. 공백에 레이어 3(키 관리) 또는 레이어 4(열거하지 않은 하위 처리자)가 포함된다면, 그것이 협상의 여지입니다.
- 셀프호스팅 컨트롤 플레인으로 대안 공급업체 등록부가 어떤 모습일지 살펴보십시오. 라이선스 비용이 아닌 등록부 항목을 비교하십시오. 라이선스 비용은 2배 이내로 비슷하지만, 등록부 항목은 형태가 다릅니다. (동반 게시물 NIS2 스택의 구조적 비용에서 무엇이 제거되고 무엇이 남는지를 자세히 설명합니다.)
저희가 후보 목록의 대안이라면, 제안은 구체적입니다. 벤더 설문지를 보내십시오. 배포된 인스턴스를 기준으로 공백을 포함한 실제 답변으로 작성하겠습니다. 서류를 보내기 전에 아키텍처를 검토하고 싶다면, 창업자와 30분 아키텍처 리뷰를 예약하겠습니다. 방어 가능한 등록부 항목으로 가는 길은 화려한 브로슈어가 아닙니다. 불편한 것을 포함한 답변입니다.
Rediacc의 NIS2 조항별 역량 공개 매핑은 NIS2 및 DORA를 참조하십시오. 더 넓은 컴플라이언스 프레임은 컴플라이언스 개요, 데이터 주권, 온프레미스를 참조하십시오.