설계 및 개발 라이프사이클 후반에 솔루션에 보안을 추가하면 종종 비용이 많이 드는 재작업과 사용성 저하가 발생하여 솔루션의 기능과 사용자 경험을 저해하게 됩니다. 초기 단계부터 보안을 고려하여 솔루션을 설계하면 최종 솔루션에서 사용성, 상호운용성, 복원력 및 보안 간의 적절한 균형을 보장하는 데 도움이 됩니다.

설계 단계부터 보안 적용은 프로젝트의 설계, 개발 및 전달 실천 방식에 숙련되고 경험이 풍부한 팀이 수행하는 보안 및 규정 준수 실천 방식이 포함되어야 한다는 원칙입니다. 다음에 제시되는 것과 같은 보안 설계 원칙은 아키텍처적 사고 방식을 안내합니다.

설계 프로세스는 조직 내부 및 외부의 위험, 규정 준수 및 보안 이해관계자를 위해 필요한 사용자 결과에 집중하기 위해 엔터프라이즈 디자인 사고를 사용하는 것에서 시작해야 합니다. 외부 이해관계자에는 고객, 정부 및 규제 기관이 포함됩니다. 내부 이해관계자에는 위험, 규정 준수 및 보안을 관리하는 사람들이 포함됩니다.

설계 프로세스는 아키텍처 특성, 아키텍처 결정, 기능 아키텍처 및 클라우드 배포 모델을 정의하기 위한 아키텍처적 사고로 이어집니다. 그 다음 복원력, 성능 및 확장성과 같은 특성의 정의가 보안 서비스에 대해 완료됩니다.

요구 사항과 아키텍처를 정의한 후에는 기본 보안 원칙을 따르는 것을 포함하여 보안 기능과 인프라의 엔지니어링을 수행할 수 있습니다.

IBM은 제품 개발에서 보안 및 개인정보 보호를 설계 단계부터 적용하는 오랜 접근 방식을 가지고 있습니다. 게시된 IBM Redpaper인 개발에서의 보안: IBM® Secure Engineering Framework를 검토하는 것이 유용합니다.

시스템 내의 사용자 또는 소프트웨어가 과도한 권한을 가지고 있는 경우, 의도하지 않았거나 의도적으로 오용될 위험이 있습니다.위협 행위자는 내부 사용자의 특권 계정을 침해하고 그 권한을 사용하여 네트워크와 시스템을 이동할 수 있습니다.

최소 권한은 시스템이 사용자 또는 소프트웨어가 의도한 작업을 수행하는 데 필요한 최소한의 권한만 부여해야 한다는 원칙입니다. 시스템은 애플리케이션의 가장 상위 수준부터 두 소프트웨어 구성 요소 간의 개별 연결에 이르기까지 이 원칙을 구현해야 합니다.

최소 권한 원칙을 구현하려면 동적인 IT 환경에 존재하는 자산을 이해해야 합니다. 특권 액세스는 단순히 사람의 문제가 아니라 어떤 애플리케이션이 어떤 데이터에 액세스하고 있는지를 파악해야 하는 문제입니다. 발견, 분류 및 위험 평가의 과정은 지속적으로 이루어집니다. 디지털 자산에서 수집한 위험 데이터를 통합하여 새로운 비즈니스 수준의 위험 인사이트를 도출하고 올바른 정책을 수립하는 데 활용해야 합니다.

사용자 또는 소프트웨어는 세션의 초기 식별 및 인증 시점에는 보안 컨텍스트를 가질 수 있지만 위협 행위자가 활성 세션을 침해하여 이를 이용해 시스템을 추가로 침해할 수 있습니다.

지속적 검증은 사용자 또는 소프트웨어가 여전히 보안 컨텍스트를 유지하고 있는지를 평가하기 위해 지속적으로 검증되어야 한다는 원칙입니다. 지속적 검증의 목적은 위협 행위자보다 먼저, 가능한 한 이른 시점에 보안 문제와 취약점을 발견하는 것입니다.

지속적 검증은 2단계 인증 요청과 같은 검증 절차를 사용하여 엔티티가 주장하는 사용자 또는 시스템과 실제로 동일한지를 확인합니다. 워크로드는 제로 트러스트 네트워크 아키텍처(ZTNA)를 사용하는 솔루션을 통해 사용자와 소프트웨어의 지속적 검증을 지원하도록 업데이트가 필요할 수 있습니다. 동급 최고 수준의 사용자 경험 제공에 집중하는 조직은 불필요한 요청으로 사용자를 방해하는 것을 주저하지만 이러한 수준의 신원 보장은 제로 트러스트에 매우 중요합니다.

위협 행위자 가 이미 조직을 침해했을 수 있습니다. 조직이 외부 경계에서만 위협을 탐지하고, 유효한 메커니즘을 사용하여 경계 제어를 우회한 위협은 탐지하지 않는다면, 침해 사실을 오랫동안 알아차리지 못할 수 있습니다. 조직이 침해가 위협 행위자에 의해 발생했다고 가정하는 원칙이 침해라고 가정해 보겠습니다.

이 접근 방식은 위협 관리에서 선제적 내부 탐지를 추가하고 조기 경고 신호를 탐지하며 위협 헌팅을 수행하고 검증된 런북을 사용하는 것을 요구합니다. 탐지 및 대응은 인사이트 계층 및 정책 집행 계층과 긴밀하게 통합되어 컨텍스트를 공유하고 식별된 위협에 대응하여 액세스 제어 정책을 동적으로 조정해야 합니다.

정보 시스템에는 소프트웨어, 펌웨어 및 하드웨어에 취약점이 존재합니다. 구성과 소프트웨어는 변경되며 새로운 취약점이 나타납니다. 방어 계층 중 하나가 취약하더라도 시스템은 여전히 안전하게 유지되어야 합니다.

심층 방어는 시스템이 여러 방어 계층을 갖도록 하여 하나의 계층이 실패하더라도 다른 계층이 시스템의 민감한 데이터를 보호하도록 하는 원칙입니다. 보안 전략에 계층형 접근 방식을 사용하면 방어 계층 중 하나가 침해되더라도 조직이 이후 계층에서 공격자를 차단할 수 있습니다.

기업 보안 전략과 아키텍처에는 전통적인 네트워크 컴퓨팅 모델의 여러 계층 전반에 걸쳐 보호를 제공하는 조치가 포함되어야 합니다. 일반적으로 조직은 가장 기본적인 수준인 시스템 수준 보안부터 가장 복잡한 수준인 전송 수준 보안에 이르기까지 보안을 계획해야 합니다.

조직의 공격 표면은 위협 행위자가 네트워크 또는 민감한 데이터에 대한 무단 액세스를 얻거나 사이버 공격을 수행하기 위해 사용할 수 있는 취약점, 경로 또는 방법의 총합이며 이러한 요소를 공격 벡터라고도 합니다. 조직이 클라우드 서비스와 하이브리드(온프레미스/재택 근무) 작업 모델을 점점 더 많이 채택함에 따라 네트워크 및 관련 공격 표면은 날이 갈수록 커지고 복잡해지고 있습니다.

공격 표면 최소화는 시스템이 공격 벡터의 범위를 줄여 위협 행위자가 액세스할 수 있는 가능한 경로를 줄여야 한다는 원칙입니다. 보안 전문가는 공격 표면을 디지털 공격 표면, 물리적 공격 표면, 소셜 엔지니어링 공격 표면의 세 가지 하위 표면으로 나눕니다.

1. 디지털 공격 표면은 인터넷 연결이 있는 모든 위협 행위자에게 조직의 클라우드 및 온프레미스 인프라가 노출될 가능성을 의미합니다. 일반적인 공격 벡터에는 네트워크 액세스, 소프트웨어 취약점, 사용되지 않는 리소스의 활성화, 섀도 IT 및 오래된 소프트웨어가 포함됩니다.

2. 물리적 공격 표면은 일반적으로 조직의 물리적 사무실 또는 엔드포인트 장치에 대한 권한 있는 액세스를 가진 사용자만 접근할 수 있는 자산과 정보를 노출시킵니다. 여기에는 악의적인 내부자 공격, 장치 도난, 그리고 “미끼 공격(baiting)”이 포함되며 이는 위협 행위자가 악성코드가 감염된 USB 드라이브를 공공 장소에 두어 사용자가 이를 컴퓨터에 연결하도록 유도해 의도치 않게 악성코드를 다운로드하도록 만드는 공격입니다.

3. 사회 공학 공격 표면은 사람들이 공유해서는 안 되는 정보를 공유하거나, 다운로드해서는 안 되는 소프트웨어를 다운로드하거나, 방문해서는 안 되는 웹사이트를 방문하거나, 범죄자에게 돈을 보내거나, 개인 또는 조직의 자산이나 보안을 침해하는 다른 실수를 하도록 조작하는 것을 의미합니다.

조직은 이러한 각 공격 표면을 검토하여 시스템에서 처리되는 민감한 데이터에 대한 위험을 평가해야 합니다.

사용자는 암호화 키와 같이 통제를 우회할 수 있는 매우 민감한 데이터에 액세스할 수 있거나 대규모 금액을 이체하는 것과 같은 높은 권한이 필요한 작업을 수행할 권한을 가질 수 있습니다. 시스템이 사용자를 모니터링하더라도 사용자가 자신의 권한을 남용하여 치명적인 비즈니스 결과를 초래할 수 있습니다.

직무 분리는 데이터 또는 작업에 대한 강력한 액세스 권한을 가진 사용자가 해당 작업을 완료하려면 둘 이상의 사용자가 필요하도록 하는 원칙입니다. 이 원칙은 조직이 관리 기능을 개인 간에 분산하여 책임이 겹치지 않도록 하고 한 명의 사용자가 무제한 권한을 갖지 않도록 할 수 있게 합니다.

암호화 키 관리와 같은 활동에서는 조직이 암호화 키 관리자가 키의 서로 다른 부분을 관리하도록 요구하여 어느 한 관리자도 전체 키에 대한 지식을 갖지 못하도록 합니다. 비즈니스 거래의 경우 애플리케이션은 거래를 요청한 사람이 거래를 완료하기 위해 하나 이상의 승인자를 갖도록 요구할 수 있습니다.

일부 산업에서는 규제 기관이 강력한 기능에 대해 규제 지침의 일부로 직무 분리를 요구할 수 있습니다. 직무 분리는 기업이 정부 규정을 준수하도록 돕고 권한 관리를 단순화합니다.

제품이나 서비스에는 다양한 구성 지점이 존재하며 이를 가능한 한 쉽게 사용할 수 있도록 만들려는 요구가 있습니다. 그 결과 제품은 네트워크 포트를 열어 두거나 기억하기 쉬운 비밀번호를 허용하는 것과 같은 안전하지 않은 보안 구성을 갖게 됩니다.

기본 보안은 조직이 제품이나 서비스를 처음 사용할 때부터 보안 상태로 구성된 상태로 제공받아야 한다는 원칙입니다. 이러한 제품은 최종 사용자가 추가적인 보안 조치를 취하지 않아도 가장 일반적인 위협과 취약점으로부터 보호되도록 설정됩니다.

시스템은 처음에는 안전하게 구성될 수 있지만 이후 개발자가 구성을 변경하거나 위협 행위자가 취약점을 통해 변경을 수행하여 시스템을 침해할 수 있습니다.

지속적 규정 준수는 시스템 개발 단계부터 운영 중인 시스템에 이르기까지 시스템의 보안 구성이 지속적으로 점검되어야 한다는 원칙입니다. 지속적 규정 준수의 목적은 위협 행위자보다 먼저 보안 문제와 취약점을 발견하는 것입니다.

이상적으로 규정 준수 점검은 모두 자동화되어야 하며 클라우드 플랫폼, 컨테이너 플랫폼, 미들웨어 및 가상 서버와 컨테이너와 같은 컴퓨트 이미지 등 모든 보안 구성을 포함해야 합니다. 컴퓨팅 이미지의 경우 코드형 인프라(IaC)를 사용하여 전체 이미지를 정기적으로 교체하는 방식이 더 나은 접근 방식일 수 있습니다.

하이브리드 클라우드 환경에서 보안 및 규정 준수를 제공하기 위한 공유 책임은 워크로드나 애플리케이션이 사용하는 서비스 모델, 컴퓨트 플랫폼 및 클라우드 서비스 공급자에 따라 달라집니다. 보안 아키텍트는 보안 서비스의 설계, 구축 및 운영을 포함하는 책임을 문서화하고 전달해야 합니다. 명확성이 없으면 솔루션의 보안에 공백이 발생할 수 있습니다.

각 차원은 공유 책임에 서로 다른 영향을 미칩니다.

• 클라우드 서비스 모델 - NIST의 클라우드 컴퓨팅 정의에서는 IaaS, PaaS, SaaS 또는 분산 클라우드와 같은 클라우드 서비스 모델에 따라 책임 범위가 달라집니다. 보안 서비스는 공동 책임의 일부입니다. 예를 들어 IBM® Cloud의 공유 책임에는 ID 및 액세스 관리와 보안 및 규정 준수가 포함됩니다. 이러한 범주에 대한 공유 책임은 클라우드 서비스 모델에 따라 달라집니다.
   

• 컴퓨팅 플랫폼 - 워크로드의 호스팅은 베어 메탈 서버, 가상 서버, 컨테이너 플랫폼 및 서버리스와 같은 하나 이상의 컴퓨트 플랫폼에서 이루어질 수 있습니다. 각 컴퓨트 플랫폼은 서로 다른 공유 책임 집합을 가집니다. 예를 들어 Bare Metal Servers에서는 물리적 하드웨어와 네트워크 통합을 제외한 플랫폼의 모든 보안 통제에 대해 워크로드 소유자가 책임을 져야 합니다.
   

• 클라우드 서비스 공급자 - 책임은 클라우드 서비스 공급자에 따라서도 달라집니다. 예를 들어 각 클라우드 서비스 공급자의 Kubernetes 플랫폼은 서로 다른 선별된 오픈 소스 패키지 집합으로 구성되기 때문에 서로 다릅니다(Red Hat OpenShift를 사용하는 경우 제외).

그렇다면 보안 아키텍트는 서비스 소유권의 차이에 왜 관심을 가져야 할까요? 보안 운영을 제공하는 팀은 서비스 운영을 지원하기 위해 사전에 정의된 보안 서비스를 보유하고 있을 수 있습니다. 보안 서비스는 클라우드 플랫폼의 일부일 수도 있고 광범위한 통합이 필요한 온프레미스 환경에 존재할 수도 있습니다.

예를 들어 내부 보안 운영 팀은 IBM® Consulting과 같은 글로벌 시스템 통합업체(GSI)와는 다른 기술을 사용할 수 있습니다. 내부 보안 팀의 경우 보안 서비스를 호스팅하는 보안 제어 플레인이 온프레미스에 있을 수 있는 반면 GSI는 다른 클라우드 서비스 공급자가 제공하는 클라우드 보안 서비스를 사용할 수 있습니다.

서비스형 소프트웨어(SaaS) 클라우드 서비스 모델에서는 클라우드 서비스 소비자가 사용할 수 있는 것은 애플리케이션 보안 관리뿐입니다. 보안은 일반적으로 서비스의 일부로 애플리케이션에 내장되어 있으며 보안 구성을 제어할 수 있는 범위는 제한적입니다. 이 경우 SaaS 공급자가 대부분의 보안 운영 책임을 맡습니다.

책임이 문서화되어 있지 않으면 워크로드 실행에 의존하는 보안 구성 요소를 설계, 구축 및 운영할 책임자가 지정되지 않을 수 있습니다. 보안 서비스에 대한 공유 책임을 이해하면 솔루션 아키텍처가 운영 요구 사항을 충족할 수 있으며 프로젝트의 이후 단계에서 솔루션을 다시 작업하는 것을 방지할 수 있습니다.

하이브리드 클라우드 아키텍처의 보안 서비스는 서로 다른 클라우드 서비스 모델, 컴퓨트 플랫폼 및 클라우드 서비스 공급자를 사용합니다. 이러한 서비스는 보안 및 규정 준수에 대해 일관된 관리와 감독을 제공하기 위해 합의된 제어 플레인 아키텍처가 필요합니다.

온프레미스 데이터 센터 워크로드를 보유한 기업의 경우 클라우드 서비스 공급자 장애에 대비한 복원력을 확보하기 위해 제어 플레인이 온프레미스 데이터 센터에 위치할 수 있습니다. 그러나 온프레미스 보안 서비스가 클라우드 플랫폼을 완전히 관리할 수 있는 능력을 반드시 갖는 것은 아닙니다. 따라서 서로 다른 클라우드 서비스 공급자 전반에서 보안 상태를 보고하고 위험을 식별할 수 있도록 제어 플레인 아키텍처를 설계해야 합니다.

클라우드 기반 조직의 경우 컨트롤 플레인의 호스팅은 또 다른 클라우드일 수 있으며, PoP(Point of Presence)에서 호스팅되거나 코로케이션 데이터 센터에서 호스팅될 수 있습니다. 클라우드 서비스 제공업체에 장애가 발생한 경우에도 보안 컨트롤 플레인을 사용할 수 있어야 할 수 있습니다.

보안 아키텍트는 조직 전반에서 보안 제어 플레인 아키텍처에 대한 정렬을 보장하기 위해 아키텍처 결정을 문서화하고 합의하는 것이 중요합니다. 솔루션이 조직의 전략을 충족하도록 프로젝트 초기 단계에서 이러한 결정을 내려야 합니다.

보안은 단순히 보안 기능을 배포하는 것이 아니라 위협으로부터 비즈니스 데이터와 프로세스를 보호하는 것입니다. 시스템을 통과하는 데이터 흐름을 추적하기 위한 체계적인 접근 방식을 사용하여 전송 중, 저장 중 및 사용 중인 데이터를 보호하기 위한 보안 통제를 식별해야 합니다.

아키텍트는 시스템 경계와 시스템을 통한 데이터 흐름을 시작하는 외부 상호작용을 식별하기 위해 시스템 컨텍스트 다이어그램부터 시작하여 보호해야 할 민감 데이터를 식별해야 합니다. 그 다음 애플리케이션의 내부 데이터 흐름은 컴포넌트 다이어그램과 같은 기능 구성 요소를 설명하는 다이어그램을 사용하여 분석됩니다.

아키텍트가 구현 단계로 이동하면 클라우드 아키텍처 다이어그램을 사용하여 클라우드 인프라에 배포된 구성 요소 간의 데이터 흐름을 분석합니다. IBM은 클라우드 서비스 공급자와 독립적인 설계를 가능하게 하는 기술 다이어그램 설계 언어를 만들었습니다.

이러한 데이터 흐름에 대한 위협을 식별하기 위해 워크로드의 기능 구성 요소와 워크로드 인프라 모두에 대해 위협 모델링을 사용해야 합니다.

이러한 기술과 산출물은 보안 및 규정 준수를 위한 아키텍처 사고에 대해 반복 가능하고 일관된 접근 방식을 제공합니다.

가장 민감한 데이터를 처리할 때는 기밀 컴퓨팅과 동형 암호화를 사용하여 추가적인 보호 계층을 고려해야 합니다.

시스템은 다양한 통제 요구 사항을 충족해야 하며 그 목록은 길어지고 관리하기 어려워질 수 있습니다. 많은 개별 요구 사항을 직접 관리하는 대신 요구 사항을 전달 기능으로 그룹화하는 프로세스, 서비스 또는 기능 단위로 관리해야 합니다. 예를 들어 ID 라이프사이클 관리나 비인가 구성 요소 탐지와 같은 기능이 전달 기능이 될 수 있습니다.

규정 준수를 보다 효과적으로 관리하려면 다음 단계를 따르세요.

1. 원래 출처까지 추적할 수 있는 단일 규정 준수 프레임워크를 구축하세요.
2. 규정 준수 프레임워크의 요구 사항을 전달 기능 세트에 매핑하세요.
3. 설계, 구축, 테스트 및 운영의 모든 단계에서 규정 준수 기능이 확보되도록 하세요.
4. 프로덕션 환경에서도 요구 사항을 계속 준수하세요.

보안 아키텍트는 보안 기능에 관련된 서비스 수준 목표(SLO), 책임 합의 등과 같은 요소가 포함되도록 해야 합니다.

한 고객, 사업 부문 또는 환경의 데이터가 다른 곳으로 유출되지 않도록 보장해야 하는 경우가 많습니다. 워크로드 실행과 데이터 저장 모두에서 분리가 이루어져야 합니다. 이는 데이터베이스의 다른 테이블을 사용하는 방식이나 별도의 물리 서버를 사용하는 방식처럼 단순할 수도 있습니다.

하이브리드 클라우드는 데이터 처리 분리를 적용할 수 있는 다양한 옵션을 제공합니다. 분리는 다음 사이에서 이루어져야 합니다.

1. 워크로드 또는 애플리케이션 - 예: 회계 vs 인사
2. 환경 - 예: 개발, 테스트 및 운영
3. 고객 - 예: 고객 A vs 고객 B
4. 위치 - 예: 영국 vs 미국

하이브리드 클라우드 환경에서는 서로 다른 기능과 보장 수준을 제공하는 다양한 분리 옵션이 있습니다.

1. 엔터프라이즈 계정
2. 클라우드 계정
3. 리소스 그룹
4. 가상 프라이빗 클라우드
5. 실행 도메인 - 예: 컨테이너 또는 서버 이미지
6. 설명
7. 키 관리 도메인
8. 물리 장치

조직 정책은 데이터를 처리하는 워크로드에 어떤 유형의 분리가 적절한지 정의해야 합니다. 예를 들어 정책에서 프로덕션 고객 데이터를 호스팅하는 환경은 비프로덕션 환경이 아니어야 한다고 요구할 수 있습니다. 필요한 최소 수준의 분리는 서로 다른 클라우드 계정이며 그곳에서 ID 및 액세스 관리가 이루어집니다.

데이터 분리와 관련된 주제로 데이터 주권이 있습니다. 일부 국가에서는 데이터 처리와 액세스가 이루어질 수 있는 위치에 제약을 두고 있습니다. “주권 클라우드를 통해 규제에 대응하고 혁신을 추진하기” 블로그 게시물에서는 데이터 주권 요구 사항의 계층 구조에 대해 설명합니다.

위협 모델링은 시스템을 통과하는 데이터 흐름에 대한 보안 통제를 식별하고 검증하는 기법으로 자주 인식됩니다.

그러나 위협 모델링에는 두 번째 목적이 있으며 그것은 위협 모니터링 시스템에서 모니터링할 위협을 식별하는 것입니다. 보안 아키텍트는 우선순위가 지정된 위협 목록을 식별하기 위해 작업해야 합니다. 그 다음 위협 탐지 기능을 위한 위협 탐지 사용 사례를 정의합니다. 위협에 효과적으로 대응할 수 있도록 사고 대응 런북과 함께 탐지 사용 사례를 구현하고 테스트하세요.

프로젝트의 완전한 설계와 구현을 보장하기 위해 위협, 위협 탐지 사용 사례 및 사고 대응 런북 간의 추적 가능성이 문서화되도록 하세요.

과거의 온프레미스 데이터 센터에서는 보안 운영 팀이 며칠 또는 몇 시간 내에 작업을 완료했으며 엄격한 서비스 수준이 필요하지 않았습니다. 코드형 인프라(IaC) 자동화 환경에서는 시크릿 관리나 인증서 관리와 같은 중앙 보안 서비스가 중단될 경우 애플리케이션의 가용성에 즉각적인 영향을 미칩니다. 따라서 보안 서비스에는 가용성 요구 사항을 충족하기 위한 서비스 수준과 아키텍처가 필요합니다.

각 보안 기능 또는 서비스에 대해 다음을 정의하세요.

1. 서비스 운영 시간
2. 사고, 문제 및 변경 대응 시간
3. 운영 인력의 기술과 경험
4. 서비스 요구 사항에 맞는 상세하고 검증된 절차
5. 서비스 요구 사항에 맞는 자동화

내부 보안 운영 팀이 클라우드 네이티브 워크로드의 요구 사항을 충족할 수 없다면 관리형 보안 서비스 제공업체의 활용을 고려하세요.

생각해 보면 오늘날 많은 보안 서비스는 자신이 지원하는 워크로드와 최소한 동일한 수준의 복원력과 서비스 수준이 필요합니다.

과거의 작업 방식에서는 보안이 사후 고려 사항이었기 때문에 개발 라이프사이클 초기 단계에서 보안 구성을 적용하거나 패치를 수행하기가 어려웠습니다. DevOps 작업 방식에서는 보안 빌드 표준이 다음을 충족해야 합니다.

1. 개발 및 테스트 환경에 포함되어야 합니다.
2. 초기 개발 단계부터 전체 프로덕션 단계까지 일관성을 유지해야 합니다.
3. 지속적인 규정 준수를 위해 계속 테스트되어야 합니다.

빌드 프로세스는 보안이 사후 고려 사항이 되지 않도록 개발과 운영의 모든 단계에서 워크로드가 안전하지 않은 방식으로 배포되는 것을 방지해야 합니다.