보안은 클라우드 채택에 필수적이며, 보안의 부재는 종종 클라우드 채택의 관심의 대상이 된다. 하지만, 늘어나는 보안 정책 및 준수 복잡도, IT 복잡도 및 IT 애질리티로 인해 보안 정책을 보안 구현 방식으로 변환하는 태스크는 더 시간이 많이 들고 반복적이며 비용이 많이 들고 오류가 발생하는 경향이 있으며 일반 사용자 조직에 대규모의 보안 노력에 분명히 이르게 될 수 있다. 자동화는 일반 사용자 조직(및 클라우드 제공자)이 해당 노력을 줄이고 정책 구현 정확도를 개선하는 데 도움을 줄 수 있다. 이 기사에서는 특히 흥미롭고 어려우며 자주 잊혀지는 주제에 주목한다. 즉, 이는 애플리케이션 계층에 대한 보안 정책 자동화이다.

클라우드 애플리케이션 보안 자동화

애플리케이션 보안 정책 자동화는 엔터프라이즈 보안 정책, 준수 규제 및 우수 사례와 같이 이해할 수 있는 보안 요구사항을 애플리케이션 계층에서 강제한 일치하는 기술적 보안 정책 규칙 및 구성으로 변환하는 프로세스를 자동화하는 것에 관련된다. 루프를 닫기 위해 이는 감사의 자동화도 포함한다. 예를 들어, 애플리케이션 계층 경보를 수집하고 지속적으로 보안 태도를 평가하기 위해 이해할 수 있는 보안 및 준수 요구사항으로 다시 맵핑하는 것이다.

클라우드 애플리케이션 보안 정책의 해부

애플리케이션 보안 정책은 종종 서비스 지향 아키텍처(SOA), 클라우드 애플리케이션 매시업 및 기타 "플러그 앤 플레이(plug and play)" 애플리케이션 환경과 같은 상호 연결되고 동적으로 변경하는 애플리케이션 분야에 특히 복잡하다. 이러한 애플리케이션 환경은 다양한 비즈니스 이유로 채택되고 보안은 전체적인 유지보수 노력을 가능한 한 최소화하여 이러한 이유를 지원해야 한다. 그러므로 자동화가 핵심이다.

보안 자동화는 클라우드 사용자 수요가 클라우드 제공자로부터 규제 준수 정책 관리를 지원하므로 특히 클라우드 컴퓨팅에 중요하지만 동시에 일반적으로 클라우드 컴퓨팅에 대해 수행하는 것과 동일한 측정으로 이러한 이점을 판단한다(선행 자본 지출과 사내 수동 유지보수 노력을 얼마나 줄이는지에 따라).

일반적으로 "애플리케이션 계층 보안"은 이 기사에서 다루는 정책 자동화 측면보다 훨씬 더 폭이 넓고 취약성 스캐닝, 애플리케이션 계층 방화벽, 구성 관리, 경보 모니터링 및 분석 그리고 소스 코드 분석과 같은 태스크도 포함한다. 애플리케이션 계층 보안 정책과 특히 밀접하게 관련된 태스크는 ID 및 액세스 관리이다. ID 및 액세스 관리는 애플리케이션 보안보다 사용자 ID 관리와 더 많이 관련되는 것으로 관찰되는 반면, ID 및 액세스 관리는 실제로 애플리케이션 계층 보안과 보통 많이 관련된다. 이는 사용자가 애플리케이션에 액세스하고 인증할 때 보통 특정 액세스되는 애플리케이션에 많이 의존하는 권한 부여 정책이 강제되어야 하기 때문이다.

이 때 다음과 같이 어려운 질문이 제기된다. 이 권한 부여 정책은 어디에서 나오는가? 누가 이러한 정책을 쓰고 유지보수하는가? 어떻게 강제되는가? 어떻게 감사되는가? 이러한 문제로 인해 정책 관리가 시간이 소모되고 반복적이며 비용이 많이 들고 오류가 발생하기 쉬운 성향을 상대적으로 줄이기 위해 ID 및 액세스 관리와 함께 애플리케이션 보안 정책 자동화를 사용하기 위한 케이스가 된다.

오늘날 클라우드 애플리케이션 보안 정책 자동화 배치

일반적으로 보안 정책 자동화 그리고 클라우드에 특화된 보안 정책 자동화는 여전히 상대적으로 초기 단계이다. 이는 대부분 서비스로서 ID/인증을 중심으로 집중한다(예를 들어, Facebook 연결). 또한 일부 클라우드 기반 보안 서비스가 있으며(바이러스 방지, 이메일 스캐닝, IDS(침입 탐지 시스템), 로그 관리), 이 중 일부는 애플리케이션에 간접적으로 관련된다.

이 기사에서는 서비스로서 애플리케이션 보안 정책 자동화에 집중하고, 오늘날에는 불과 몇 가지의 얼리 어답터(early adopter) 배치만 있다. 첫 번째로 ObjectSecurity는 OpenPMF 모델 구동형 보안 정책 자동화 제품과 서비스로서 개인용 플랫폼(PaaS) 클라우드(Intalio BMS를 갖춘 Intalio Cloud)를 통합했다. 이는 클라우드 매시업을 위한 원활한 정책 자동화를 제공한다. OpenPMF와 연관된 또 다른 초기 단계 배치는 미 해군을 위한 것이며, 이는 사설 클라우드와 SOA 사이에 중간 지역 어딘가에 있다. 이는 높은 보증 환경에서 가상화된 IT 서비스를 위한 서비스로서 정책(poicy-as-a-service)을 수반한다. 두 가지 사례 연구 모두 나중에 사례 연구 섹션에서 다룬다.

모델 구동형 보안 정책 자동화의 다른 배치도 많지만 클라우드에 대한 것은 아니고 대부분은 서비스로서 정책(poicy-as-a-service)을 수반하지 않는다.

위로

애플리케이션 보안 정책 자동화의 도전과제

안타깝게도 대부분의 경우에 보안 정책 자동화는 행하는 것보다 말하는 것이 더 쉽다. 이 섹션은 애플리케이션 보안 정책 자동화를 달성하는 면에서 이렇게 어려운 이유를 개괄한다.

정책이 사람과 조직에 더 의미 있게 되므로 구현하고 자동화하기에 더 어렵다

오늘날 많은 보안 도구는 타당성, 정확성 및 자동화를 양보하면서 어느 정도의 자동화(유지보수 없음)를 제공한다. 일부 경우에 자동화된 도구는 공급업체가 일반 사용자 조직이 구현하려는 기본 보안 정책이 무엇인지 인식한다고 가정하여 제작된다. 다른 경우에는 제품이 제작되어 시간이 흐르면서 정책을 발견적으로 배운다. 두 가지 접근방식 모두의 단점은 비록 보안 메커니즘이 스스로 작동한다고 할지라도 의도하지 않은 무관하거나 완성되지 않은 정책을 구현할 가능성이 있다는 점이다.

이러한 기존의 보안 정책은 조직에 특화된 정책을 요구하지 않고 바이러스 방지, 맬웨어 방지, 사전 구성된 네트워크 침입 발견 시스템 및 일반 애플리케이션 취약성 스캐닝과 같은 기술 스택의 더 낮은 계층(예를 들어, 네트워크 또는 운영 체제 계층)을 대상으로 하는 더 일반적인 보안 도구에 더 우수하게 작동하려는 경향이 있다.

보안 자동화는 조직적, 사용자 및 애플리케이션 작동이 보안 정책을 강제하고 감사하기 위해 고려되어야 할 때 더 어려워진다. 예를 들어, 신용 카드 지불을 처리하는 조직은 "어느 신용 카드 정보도 조직을 암호화되지 않은 상태로 두어서는 안 된다" 및 "신용 카드 정보는 더 이상 사용되지 않을 때 삭제되어야 한다"와 같은 정책을 구현하려 할 것이다. 또 다른 예제는 "의사와 간호사가 현재 환자의 건강 기록에 액세스할 수 있어야 하고 작성되는 경보 감사 로그 없이 유효한 용도를 위해 액세스해야 하는 경우에만 액세스할 수 있어야 한다"와 같은 정책을 구현하려는 헬스케어 조직이 될 것이다. 이러한 복잡하고 컨텍스트적인 정책은 특정 조직의 보안 정책, 비즈니스 프로세스, 애플리케이션 및 애플리케이션 상호작용에 의존한다. 종종 이러한 복잡하고 컨텍스트적인 정책을 구현하는 이유는 일반 사용자 조직이 산업별 규제에 부합해야 하기 때문이다(PCI Data Security Standard-PCI DSS 및 Health Insurance Portability and Accountability Act-HIPAA).

정책이 점점 더 많아지고 복잡하며 기능이 풍부하며 세밀하게 되고 컨텍스트적이 되면서 구현하고 자동화하기에 더 어려워지고 있다

오늘날 ID 및 액세스 관리의 일부로 분류되는 기존의 "권한 부여 관리"는 이러한 도전과제를 보여준다. 즉, 시스템과 참여자가 많고 상호연결된 애플리케이션이 동적으로 연결되고("애질리티") 정책의 기능이 풍부해지고 세밀하게 되며 컨텍스트적일 때 정책을 관리할 수 없게 된다. 관리하기에 너무 많고 너무 복잡한 기술적 보안 규칙이 있으므로, 권한 부여 정책은 지정할 수 없거나 관리할 수 없게 될 수 있고 강제된 정책의 신뢰가 훼손될 수 있다. 위에 언급한 대로 응답해야 하는 질문은 다음과 같다. 이러한 권한 부여 정책이 어디에서 나왔는가? 누가 이러한 정책을 쓰고 유지보수하는가? 어떻게 강제되는가? 어떻게 감사되는가?

정책 자동화는 IT 분야가 애자일 성향이 더해지고 더 상호연결되면서 더 어려워진다(특히 클라우드 매시업에 대해)

클라우드 및 SOA와 같은 애자일 애플리케이션 환경에 깔려있는 채택 근거를 지원하기 위해 권한 부여 관리는 그 자체로 최소한 동등하게 애자일이 되어야 하고, 자동화되고 관리 가능하며 세밀하게 되고 컨텍스트적이어야 한다. 불행히도 잦은 동적 시스템 변경에 직면하여 일관적이고 올바른 기술적 보안 정책을 작성하고 유지보수하는 것은 주요 도전과제이다. 이는 동적 변경(예를 들어, 클라우드 매시업의)이 구현된 기술적 정책을 비효율적으로 렌더링할 수 있고 애플리케이션 보안 정책이 종종 SOA, 클라우드 애플리케이션 매시업 및 다른 "플러그 앤 플레이(plug and play)" 애플리케이션 환경과 같은 상호연결되고 동적으로 변화하는 애플리케이션 분야에 특히 복잡하기 때문이다. 이러한 단점과 무관하게 권한 부여 관리는 중요한 기술적 빌딩 블록을 형성하여 모든 보호된 자원에 대해 애플리케이션 권한 부여 정책을 강제하고 감사한다. 이는 클라우드 애플리케이션 보안에 중요한 역할을 하고 심지어 클라우드 매시업에 더 중요한 역할을 담당한다. 왜냐하면 다른 액터(사용자 또는 클라우드 애플리케이션)가 보안 정책에 따라 특정 상황에서 이렇게 수행하도록 권한을 부여 받은 경우 서로의 서비스를 호출할 수 있어야만 하기 때문이다. 중요한 권한 부여 관리 표준은 XACML(OASIS eXtensible Access Control Markup Language)이다.

규제 준수는 정책과 관련된 요구사항이므로 이는 또한 가능한 많은 자동화로 지원되어야 한다

엔터프라이즈 클라우드 사용자가 클라우드 호스트된 애플리케이션과 서비스에 대한 간편하고 낮은 유지보수(자동화된) 준수 지원을 요구하는 것은 당연하다. 이는 많은 클라우드 애플리케이션이 종종 조직의 경계를 넘나드는 규제된 정보를 처리하고(개인정보 보호정책, 건강 정보, 지불 정보) 감사해야 되기 때문이다. 준수 감사는 클라우드 스택으로 사용자 가시성이 제한되기 때문에(특히 PaaS 및 서비스로서 소프트웨어(SaaS)뿐만 아니라 서비스로서 인프라(IaaS)에 대해서도) 클라우드 사용자만의 온전한 책임이 될 수 없다. 규제 준수(보안 정책 관리 및 인시던트 모니터링과 같이)는 클라우드 플랫폼으로 부분적으로 굳혀져야 할 것이다.

블랙리스팅은 더 이상 충분하지 않으므로 화이트리스팅에 따른 정책이 필요하다

상기시키기 위해 말하자면 블랙리스팅은 블랙리스트에 없는 누구에게나 액세스를 제공함을 의미한다. 화이트리스팅은 화이트리스트 목록에 있는 사람에게만 액세스만 제공함을 의미한다.

위로

모델 구동형 보안 컴포넌트

자동화를 달성하기 위해 일부 "알고리즘"은 보안 정책 요구사항 및 해당 정책과 관련된 모든 것(사용자, 애플리케이션, 애플리케이션 상호연결 및 애플리케이션 워크플로우)을 이해할 수 있어야 하고 일치하는 기술 보안 정책 구현 방식을 자동으로 생성할 수 있어야 한다. 모델 구동형 보안은 보안 및 준수 정책 관리로 모델 구동형 소프트웨어 개발 접근방식에 깔려있는 추론을 적용하여 보안 정책 자동화의 이러한 필수 레벨을 가능하게 한다.

모델 구동형 보안

본질적으로 모델 구동형 보안은 모든 상호작용으로 애플리케이션을 분석하고 일반 보안 요구사항을 이에 적용하여 기술적 권한 부여(및 다른) 규칙을 자동으로 생성할 수 있다. 모델 구동형 보안은 추상의 높은 레벨에서 보안 요구사항을 모델링하는 것을 수반하고, 세밀한 컨텍스트적인 기술적 권한 부여(및 기타) 규칙을 자동으로 생성하기 위해 시스템, 특히 애플리케이션의 기능적 모델(다른 이해당사자가 제작)에 사용 가능한 다른 정보 소스를 사용하는 것을 수반하는 도구 지원된 프로세스이다. 모델 구동형 보안으로 입력은 일반 모델링 언어(예를 들어, Unified Modeling Language-UML) 또는 EA Frameworks(Enterprise Architecture Frameworks)를 사용하여 DSL(Domain Specific Language)로 표현된다(예를 들어, Department of Defense Architecture Framework-DODAF, Ministry of Defense Architecture Framework-MODAF 및 NATO Architecture Framework-NAF).

보안 요구사항의 캡처가 그래픽 편집기를 사용하여 수행되어야 할 필요는 없다. 즉, 이는 텍스트적인 모델 편집기를 사용하여 수행될 수도 있다(예를 들어, Eclipse와 같은 모델링 도구에서). 이는 그러면 모든 상호작용으로 애플리케이션에 대한 정보를 분석하여 강제 가능한 보안 규칙(액세스 제어 및 모니터링 규칙)으로 자동으로 변환된다.

모델 구동형 보안 런타임은 모든 보호된 IT 애플리케이션, 자동 정책 업데이트 및 정책 위반의 통합된 모니터링에 걸쳐서 보안 정책의 런타임 강제를 지원한다. 모델 구동형 보안의 첫 단계에서 규제 및 거버넌스 표준이 모델 구동형 보안 도구에서 높은 레벨 보안 정책으로 모델링된다(또는 사전 제작된 템플리트에서부터 선택됨). 그러면 이 보안 정책 모델은 보안 정책 모델 액터를 시스템 액터에 맵핑하고 보안 정책 모델에 따라 이러한 시스템 액터의 작동을 제한하여 구성하는 시스템의 기능적 모델에 적용된다.

기술적 관점에서 이러한(보안 및 기능적) 모델은 낮은 레벨의 세밀한 컨텍스트적인 보안 정책으로 자동으로 변환되고 전체 클라우드 오케스트레이션, 클라우드 매시업 또는 SOA 환경에 걸쳐 강제된다(예를 들어, 미들웨어 또는 도메인 경계로 통합된 로컬 강제 지점 사용). 로컬 강제 지점도 보안 준수 관련 이벤트의 모니터링을 처리한다. 그리고 SOA 애플리케이션(또는 해당 상호작용 구성)이 변경될 때마다 모델 구동형 보안은 보안 자동화 및 모니터링을 자동으로 업데이트할 수 있다.

요약하면 모델 구동형 보안 프로세스는 다음 단계로 나뉘어질 수 있다. 즉, 이는 정책 모델링, 자동 정책 생성, 정책 강제, 정책 감사 및 자동 업데이트이다. 이러한 각 단계가 클라우드 애플리케이션의 컨텍스트에서 어떻게 작업하는지 조사해보자.

모델 구동형 보안 아키텍처

그림 1의 다이어그램은 기본 아키텍처를 보여준다. 왼쪽 맨 위에 클라우드 기반 개발 및 매시업 환경이 표시된다(BPMS(Business Process Management System)-오케스트레이션된 웹 서비스). 이는 또한 모델 구동형 보안 컴포넌트가 정책 생성을 자동화하기 위해 개발/매시업 도구 체인에 설치되어야 함(클라우드 제공자에 의해)을 나타낸다.

맨 위 오른쪽에 일반적인 형태의 정기적인 정책 업데이트로 개발 도구에 PaaS 모델 구동형 보안 추가 기능을 제공하는 클라우드 보안 서비스가 표시된다. 즉, 이는 클라우드 보안 서비스로 제공되는 런타임 관리(모니터링/분석/보고) 기능도 표시된다.

맨 아래에 런타임 스택으로 설치되어야 하는(클라우드 제공자에 의해) Policy Enforcement(PEP) + Monitoring 지점으로 애플리케이션 서버(및 클라우드 런타임 스택의 나머지)에 배치되는 일부 클라우드 서비스가 표시된다.

애플리케이션이 배치되고 통합될 때, 모델 구동형 보안은 애플리케이션과 정책 모델을 자동으로 분석하고 자동으로 관련 PEP/Monitoring 지점으로 밀어 넣는 기술적 규칙을 생성한다. 보호된 어느 서비스 사이에나 메시지가 전달될 때마다 모델 구동형 보안은 기술 정책을 자동으로 평가하고 강제하며 — 필요한 경우 — 인시던트 경보를 클라우드 보안 서비스의 런타임 보안 정책 관리 기능으로 밀어 넣는다.

혜택

모델 구동형 보안이 효율적으로 사용될 때(사례 연구 참조), 다음과 같은 수많은 혜택이 있다.

• 이는 수동 관리 오버헤드를 줄이고 자동화를 통해 비용/시간을 절약한다(정책 생성, 강제, 모니터링, 업데이트) — 특히 애자일 소프트웨어 애플리케이션에 대해 그렇다.
• 이는 또한 보안 위험을 줄이고, 인적 오류 잠재성을 최소화하고 보안 구현 사항이 항상 비즈니스 요구사항 및 시스템의 기능적 작동에 맞도록 보장하여 시스템의 보안 및 안전성 둘 다 개선하여 보증을 높인다.
• 게다가 이는 보안 사일로에 걸쳐서 일관적으로 정책을 통일한다(예를 들어, 다른 애플리케이션 런타임 플랫폼).
• 마지막으로 이는 애자일 승인에 더 자동화된 모델 구동형 접근방식의 일부를 형성한다.

약점

모델 구동형 보안 채택은 때로는 다음 몇 가지 이유로 인해 여전히 어려워진다.

• 애플리케이션 스펙과 합리적으로 올바르게 정의된 Software Development Life Cycle-SDLC에 대한 의존성. 하지만 상호연결된 시스템의 모델링 측면(특히 클라우드 매시업 상호작용)은 최첨단 클라우드 PaaS 및 매시업의 중요한 부분인 동시에 강력한 시스템 설계의 부분이기도 하다.
  
  
• 모델링 시스템 및 보안 정책의 노력. 하지만, 올바른 단위(예를 들어, 클라우드 매시업 모델)로 시스템을 모델링하는 것은 실제로 정책 관리의 총 비용을 더하지 않는다. 이는 보안 관리자의 도구가 모델 구동형 보안을 지원하지 않기 때문에 보안 관리자가 자세한 기술 보안 규칙을 수동으로 지정해야 하는 경우. 이들이 정책 관리 도구 내에 애플리케이션 스펙의 보안 관련된 측면을 효율적으로 지정하고 있기 때문이다. 실제로 이는 단순하지 않은(non-trivial) 시스템에서는 불가능하며, 특히 전체 시스템 라이프사이클에 대해 불가능하다. 모델 구동형 보안은 애플리케이션과 워크플로우를 더 잘 이해하는 전문가(애플리케이션 개발자/통합자 및 프로세스 모델러)가 지정한 모델(및/또는 도구)로부터 간단히 이러한 정보(이는 종종 보안 정책 규칙의 더 큰 부분을 구성함)를 재사용한다.

실제적인 경험에서 보면 잠시 동안만 운영한 후에라도 모델 구동형 보안은 시스템을 보호하는 노력의 비용을 막대하게 줄일 수 있고 기존의 수동 정책 정의 및 관리에 비교하면 보안 및 안전을 개선할 수 있다.

위로

클라우드 애플리케이션 보안 정책 자동화 달성하기

클라우드 PaaS가 부상하면서 최대 자동화로 클라우드 애플리케이션과 매시업을 보호하고 감사하기 위해 설명한 모든 또는 일부분의 모델 구동형 보안 아키텍처를 클라우드로 이동하는 것이 합리적이다. 특히, 보안 정책 모델은 클라우드 서비스로서 애플리케이션 개발 및 배치 도구(policy-as-a-service)에 제공되며 정책 자동화는 클라우드 애플리케이션 배치 및 런타임 플랫폼으로 임베드된다(자동화된 정책 생성/업데이트, 강제, 모니터링).

다른 클라우드 배치 시나리오는 가능하다. 예를 들어, 개발 도구 및 애플리케이션 플랫폼에서 보안 기능은 PaaS 프로비저닝의 일부와 동일한 클라우드 서비스에 모두 호스트되거나 일부 보안 기능도 개별적으로 호스트된다(특히 정책 구성 및 모니터링). 이는 로컬 클라우드 외의 배치와는 다르다. 여기에서 모델 구동형 보안은 내부에서 관례대로 설치하거나 수많은 로컬 런타임 애플리케이션 플랫폼(예를 들어, 웹 애플리케이션 서버)에서 애플리케이션을 보호하고 로컬 모니터링 및 보고를 지원하기 위해 개발 도구(Eclipse와 같이)와 함께 로컬로 설치한다.

이전에 설명한 대로 일반적인 모델 구동형 보안 프로세스는 다음 단계로 나뉘어질 수 있다. 즉, 이는 정책 모델링, 자동 정책 생성, 정책 강제, 정책 감사 및 자동 업데이트이다. 이러한 각 단계가 클라우드 애플리케이션의 컨텍스트에서 어떻게 작업하는지 조사해보자. 클라우드의 컨텍스트에서 모델 구동형 보안의 다섯 단계는 아래 설명된다.

클라우드에서 정책 구성(policy-as-a-service)

모델 구동형 보안의 클라우드 버전에서 정책 구성은 구독 기반 클라우드 서비스로서 애플리케이션 개발 도구에 제공될 수 있다. 애플리케이션 개발자 및 보안 전문가에게 클라우드 서비스로서 오퍼링 스펙, 유지보수 및 정책 모델의 업데이트는 중요한 혜택이 있다. 가장 중요하게도 지속적으로 모델 구동형 보안에 사용되는 정책 모델을 지정(또는 구입 및 설치) 및 유지보수하지 않고 애플리케이션 개발자와 보안 전문가는 이제 모델의 세부사항을 알 필요 없이 필요한 정책 피드의 종류에 간단히 구독할 수 있다.

서비스로서 정책(policy-as-a-service) 제공자(클라우드 제공자와 일반적으로 다름)는 정책 모델링, 유지보수 및 업데이트에 주의한다. 다른 혜택은 최신 정책 모델이 지속적으로 피드로 제공될 것이기 때문에 사용자 조직은 보안 및 준수 전문가가 되지 않아도 되고 구독 모델로 인해 선행 비용 장애물이 최소화되며 일반 사용자가 변화를 위해 규제 및 우수 사례를 지속적으로 모니터할 필요가 없다는 점이다.

더 복잡한 정책의 경우 일부 간단한 설정 및 보안 관련 정보의 일부 잠재적인 태깅이 필요할 수 있다. 예를 들어, PCI DSS 정책 모델 구독의 경우, 지불 정보 관련 인터페이스는 애플리케이션 매시업 모델과 함께 태그되어야 할 수 있다. 사전 패키지된 클라우드 모델이 클라우드에 더 많이 통합되면 될수록 일반 사용자 조직에 의한 태깅이 더 적게 필요하다. 왜냐하면 클라우드 제공자가 이미 클라우드 모듈을 사전에 태그할 수 있기 때문이다(예를 들어, 지불 처리 모델을 위한 PCI 관련 태그).

일반적으로 설명한 아웃소싱 모델은 새로운 것이 아니다. 이는 바이러스 방지 및 스파이웨어 방지와 같이 보안의 다른 측면을 위해 수 년간 사용되었다. 사용자들은 바이러스 방지 제공자로부터 정책 피드에 간단하게 구독하고 바이러스 방지 소프트웨어 클라이언트가 해당 정책을 자동으로 강제할 수 있다(하지만 바이러스 방지와는 달리 이 기사에서는 클라우드 애플리케이션 보안에 적용되는 아웃소싱 모델을 시연한다).

클라우드 기반 권한 부여 정책 관리 서비스(특히 미션 크리티컬(mission-critical) 환경에 대해)의 신뢰성과 안정성을 의심하는 것이 자연스럽긴 하지만, 이러한 배치 시나리오의 시사점은 보호된 클라우드 애플리케이션의 신뢰성 및 안정성의 상속 레벨과 관련된 것으로 보여야 한다. 보호된 클라우드 서비스 자체가 인터넷을 통해 액세스 가능하다면, 정책 관리 서비스에서 많은 공격들(예를 들어, 서비스의 거부)이 보호된 서비스 그 자체로 향할 수도 있다 — 이 경우에 클라우드 기반 정책 관리자는 위험에 추가하지 않는다. 신뢰성 및 안정성이 더 많이 필요하면, Qos(Quality of Service)가 사용된 사설 클라우드가 있다고 가정할 때, 정책 관리자와 보호된 서비스 둘 다에 더 견고해진 인프라가 필요할 것이다. 요약하면 클라우드 기반 보안 정책 관리는 많은 조직에 공급되는 많은 서비스에 올바른 선택이 되겠지만 모두에 해당되는 것은 아니다.

클라우드에서 자동 기술 정책 생성

모델 구동 보안의 자동 정책 생성 기능은 개발, 배치 및 매시업 도구(기능적 애플리케이션 정보에 액세스를 얻기 위해)로 통합된다. 이는 이전 섹션에서 설명한 정책 피드를 소모한다. PaaS는 종종 클라우드 호스트된 개발 및 매시업 도구와 클라우드 호스트된 런타임 애플리케이션 플랫폼을 둘 다 포함한다. 이 경우에 모델 구동형 보안을 사용하는 자동 기술 정책 생성은 클라우드로 이동될 수 있으므로 기술 보안 정책은 클라우드 호스트된 개발, 배치 및/또는 매시업 프로세스 도중에 애플리케이션을 위해 자동으로 생성될 수 있다. 이는 특히 매시업 도구의 경우에 해당된다. 왜냐하면 이러한 도구가 클라우드 호스트되는 경향이 더 높고 종종 그래픽 및/또는 모델 구동형이며 클라우드 서비스 사이에 상호 작용 및 정보 플로우와 관련되기 때문이다. 개발 도구가 PaaS 클라우드에 호스트되지 않으면 모델 구동형 보안 기술 정책 자동 생성 기능은 로컬 개발 도구로 통합되어야 한다.

클라우드에서 자동 보안 정책 강제

정책 강제가 PaaS 애플리케이션 플랫폼으로 자연히 통합되어야 하므로 생성된 기술 정책은 클라우드 서비스가 액세스될 때마다 자동으로 강제된다. 이전 섹션에서 설명한 대로 정책은 호스트된 모델 구동형 보안 및 PaaS 개발 도구를 사용하여 클라우드 내에 생성되거나 로컬 모델 구동형 보안 및 개발 도구로부터 업로드된다.

정책 강제 지점이 PaaS 애플리케이션 플랫폼으로 빌드되는 방법은 PaaS 애플리케이션 플랫폼의 여부에 따라 달라진다. 즉, 정책 강제 지점의 설치를 허용하고(예를 들어, 다양한 오픈 소스 PaaS 플랫폼. 사례 연구 참조) 표준 기반 정책 강제 지점(예를 들어, OASIS XACML)을 지원하거나 독점 정책 강제 지점을 지원한다.

클라우드로 자동 정책 모니터링

정책 강제 지점은, 특히 차단된 호출과 관련된 인시던트에 대해 대개 보안 관련 런타임 경보를 일으킨다. 콜렉션, 분석 및 이러한 경보의 시각적 표현은 클라우드로 이동될 수도 있다. 이는 다음과 같은 무수한 혜택이 있다. 인시던트는 다른 정보와 함께 여러 클라우드 서비스에 대해 중심부에서 분석될 수 있다(네트워크 침입 탐지와 같이). 또한 여러 클라우드 서비스에 걸쳐서 보안 태도의 통합된 시각적 표현이 제공될 수도 있다. 통합된 인시던트 정보는 감사 프로세스를 위해 보관될 수 있으며 준수 관련 의사결정 지원 도구는 클라우드 서비스로 제공될 수 있다.

자동 업데이트하기

설명한 모델 구동형 접근방식은 애플리케이션 및 특히 상호작용이 변경될 때마다 기술 보안 정책 강제 및 감사의 자동 업데이트를 사용한다. 보안 정책 요구사항이 변경될 때 동일한 자동화가 가능하다.

일반 사용자 조직 및 클라우드 제공자가 보안 정책 자동화를 어떻게 사용할 수 있는가

설명한 서비스로서 정책(policy-as-a-service) 접근방식은 일반 사용자 조직 및 클라우드 제공자로부터 부담을 많이 덜어낸다.

• 일반 사용자 조직에서 보안 전문가는 클라우드 구독으로 간단히 서비스로서 정책(policy-as-a-service) 보안 옵션으로 구독해야 하고, 잠재적으로 일부 간단한 보안 태깅 기능을 채택해야 하며(또는 개발자를 교육) 준수 보고서를 정기적으로 확인해야 한다. 하지만 이러한 일이 발생하기 전에 보안 전문가를 위한 중요한 작업은 클라우드 제공자로부터 정책 자동화를 요구하는 것이다(특히 사설 클라우드에 대해).
  
  
• 일반 사용자 조직에서 애플리케이션 개발자/통합자는 클라우드 제공자가 제공하는 매시업/개발 도구를 강화한 서비스로서 정책(policy-as-a-service)을 간단히 사용해야 하고 일부 간단한 보안 태깅 기능을 잠재적으로 채택해야 한다.
  
  
• PaaS 클라우드 제공자는 정책 자동화를 구현하기 위해 다음 단계를 거쳐서 일반 사용자 조직에 이러한 단순성을 모두 사용할 것이다. 먼저, 이들은 서비스로서 정책(policy-as-a-service) 제공자로 구독 및 서비스 레벨 계약을 설정할 것이다. 그 다음으로 서비스로서 정책(policy-as-a-service) 제공자로부터 모델 구동형 보안 자동화 소프트웨어 및 강제/모니터링 소프트웨어를 받아 PaaS 매시업/개발 도구 및 런타임 플랫폼에 각각 이를 설치해야 한다. 이들은 또한 관련된 보안 구독 옵션, 매뉴얼 및 서비스로서 정책(policy-as-a-service) 제공자가 작성한 준수 보고서로 액세스를 통해 일반 사용자 조직을 제공해야 할 것이다. 가까운 시일 내에 사설 클라우드 제공자는 공용 클라우드 제공자보다 이러한 서비스를 제공할 가능성이 더 높을 것이다(아래 사례 연구 참조). 왜냐하면 사설 클라우드는 미션 크리티컬(mission-critical) 사용에 더 많이 사용되기 때문이다.

새로운 개념인가 아니면 이전에 사용되었는가?

일부 보안 도구는 클라우드 서비스로(security-as-a-service) 사용 가능하다. 예로는 웹 애플리케이션 테스트가 있다. 하지만, 클라우드 서비스로서(policy-as-a-service) 권한 부여 관리를 위한 모델 구동형 보안은 주로 표준의 느린 채택으로 인해 특히 PEP에 이전에 구현되지 않았다(저자가 아는 한). 저자는 클라우드 제공자와 직접 협력하여 OpenPMF 참조 구현 방식에 대해 이 문제를 방지했다(사례 연구 참조). 이 방식으로 적절한 통합 지점은 인프라로 개발될 수 있었다.

위로

사례 연구

이제 일부 케이스를 살펴보자.

사설 클라우드를 위한 애플리케이션 보안 정책 자동화

ObjectSecurity의 OpenPMF는 수많은 다른 기술에 대해 애플리케이션 보안 정책 자동화를 구현한다. 기존의 설치에서 OpenPMF는 로컬 개발, 오케스트레이션 및 내부에 상주하거나 로컬로 설치되는 개발 도구(예를 들어, Eclipse, Intalio BPMS)와 함께 준수 모니터링/보고 도구 추가 기능으로 수많은 플랫폼(다양한 웹 애플리케이션 서버, Java EE, Data Distribution Service-DDS, CORBA/CORBA Component Model-CCM)에서 애플리케이션을 보호하기 위해 사용되었다. PaaS가 부상하면서 OpenPMF 자체를 클라우드 서비스로 요청 시 사용 가능하게 만드는 것도 타당했다.

예를 들어, 사설 클라우드에 대한 애플리케이션 보안 정책 자동화의 경우, 로컬 정책 자동화로부터 클라우드 기반 정책 자동화로 설명한 이동은 Intalio 클라우드로 통합되었다. Intalio 클라우드는 비즈니스 프로세스 모델링(아래 그림 참조)을 사용하여 애플리케이션 개발 및 통합과 웹 서비스 기반 런타임 플랫폼을 비롯한 정책 자동화의 필수 전제조건을 포함하는 전체 스택의 오픈 소스 클라우드 오퍼링이다. OpenPMF의 현재 기술 통합은 개발(Intalio BPMS/Eclipse), 런타임(Apache Axis2) 및 인증/암호화(Secure Sockets Layer-SSL/Transport Layer Security-TLS)를 위해 완료된다. 그림 3은 BPM 웹 서비스 오케스트레이션 도구로 임베드되는 정책 자동화 기능을 보여준다(메뉴 OpenPMF > Generate Security Policy). 클릭하면 특정한 애플리케이션에 대한 자세한 기술 보안 규칙이 자동으로 생성된다(그림 4).

클라우드 및 SOA용 모델 구동형 보안 배치

모델 구동형 보안 정책 자동화는 현재 애플리케이션 보안 정책 자동화 벤더인 ObjectSecurity와 정부 및 산업에 안전한 기술의 제공자이며 주요 계약자인 Promia에서 미 해군을 위해 실제 운영중인 배치에서 구현되었다. 배치는 이 기사에서 설명한 것보다 훨씬 더 포괄적이다. 즉, 이는 클라우드 및 SOA 스택의 모든 계층을 다루고 특히 애플리케이션, 미들웨어, 가상 머신, 운영 체제 및 네트워크를 다룬다. 해당 프로젝트는 특히, 애자일 변경, 신속한 인증 및 승인 그리고 유연한 정책 관리를 빠르게 진척시키는 시설 면에서 상호연결된 SOA 및 클라우드 애플리케이션을 동적으로 변경하기 위해 정보 보증을 효율적으로 관리하는 수단을 제공한다.

사용된 기술은 다음을 포함한다(그림 6 참조). ObjectSecurity OpenPMF 모델 구동형 보안, 애플리케이션 보안 모니터링 및 정책 관리; Promia Raven 침입 탐지, 모니터링, 감사 및 XML 정보 교환 기능; 안전한 개발 라이프사이클을 강제하는 보안 강화된 클라우드 및 SOA 개발 및 배치 도구; 권한 부여를 배포하는 규모 가변적인 ZBAC(Authorization Based Access Control); SOA/클라우드 애플리케이션 및 보호를 호스트하는 전체 스택 보호로 견고해진 신뢰를 갖춘 런타임 플랫폼 그리고 전세계적인 전체 스택 정책 관리 및 자동화, 보고, 승인 자동화 및 의사결정 지원, 구성, 버전화, 스캐닝 및 테스팅을 갖춘 관리 시스템

위로

결론

결론적으로 이 기사에서는 클라우드 매시업과 같은 애자일 배포된 애플리케이션 분야에 대해 보안 및 준수 정책 관리가 애자일되고 관리 가능하고 신뢰 가능하며 규모 가변적이 되기 위해 모델 구동형으로 자동화되어야 한다는 것을 보여준다. 이는 두 가지 핵심 개념을 수반한다. 첫 번째는 정책 구성이 구독 기반 클라우드 서비스로서 애플리케이션 개발 도구(policy-as-a-service)에 제공된다. 두 번째는 기술 정책 생성, 강제, 감사 및 업데이트가 클라우드 애플리케이션 개발 및 런타임 플랫폼으로 임베드된다. 클라우드 애플리케이션 및 매시업을 위한 보안 및 준수 정책 자동화를 클라우드로 이동하여 클라우드 애플리케이션과 매시업은 클라우드 채택의 저변에 깔린 전체적인 추론 내에서 더 원활하게 보호된다. 이는 또한 클라우드 애플리케이션을 위한 안전한 소프트웨어 개발 라이프사이클을 개선하고 간소화한다.

여기에 모델 구동형 보안 자동화로 시작하는 다음 단계를 위한 몇 가지 구체적인 권장사항이 있다.

• 시도하기
  클라우드 제공자는 보안 정책 자동화를 플랫폼으로 임베드하는 것을 시도해야 한다(예를 들어, 시작하려면 ObjectSecurity for Eclipse의 무료 체험판 받기). 클라우드 사용자의 경우 모델 구동형 매시업 및 정책 자동화 또는 최소한 권한 부여 관리를 지원하는 IaaS 또는 PaaS 클라우드에서 클라우드 애플리케이션을 빌드하고 있으면 모델 구동형 보안 정책 자동화를 시도한다(예를 들어, Intalio Cloud용 ObjectSecurity의 도구의 무료 체험판 받기).
  
  
• 계획하고 비전 납득시키기
  클라우드 채택의 계획 단계에 있다면 시작부터 올바르게 구현하지 않았다면 정책 자동화를 지원하기 위해 아키텍처를 계획해야 한다. 모델 구동형 매시업 도구는 정책 자동화를 지원하는 면에서 특히 효율적이고, 정책 자동화 및 매시업 도구를 둘 다 관리 부서에 납득시킬 때 "총합은 부분보다 더 크다" 논쟁을 사용할 수 있다.
  
  
• 가능한 경우 클라우드 제공자로부터 정책 자동화 요구하기
  기술 및 접근방식이 사용 가능하고 클라우드 보안을 처리하는 데 더 비용 효율적으로 어떻게 도움을 줄 수 있는지 클라우드 제공자에게 제시한다. 기본적으로 클라우드 제공자는 보안 전문가들이 그들의 직무를 최선을 다해 수행하는 면에서 지원하지 않는 "받아들이느냐 거절하느냐"의 클라우드 오퍼링을 제공하는 것처럼 보인다. 안타깝게도 일부 클라우드 제공자(특히 PaaS)는 인프라를 열지 않으므로 자체적인 정책 자동화 제품을 통합하는 것은 도전과제가 될 수 있다. 보안 전문가는 클라우드 제공자를 올바른 방향으로 이동하거나 더 열린 클라우드 제공자를 선택하기 위해 올바른 질문을 제기해야 한다.
  
  
• 적절할 때 써드파티 서비스로서 정책(policy-as-a-service) 통합하기
  더 큰 규모의 조직을 위해 사설 클라우드를 배치하는 경우 표준에 따른 써드파티 클라우드 애플리케이션 보안 정책 자동화 제품의 사용을 고려한다. 이러한 방식에서는 써드파티 보안 전문가로부터 서비스로서 정책(policy-as-a-service)을 구독할 수 있는 동시에, 애플리케이션 계층 강제는 클라우드 제공자의 표준 기반 기능으로 수행된다(예를 들어, XACML(eXtensible Access Control Markup Language)).
  
  
• 적절할 때 써드파티 인시던트 모니터링 및 분석 서비스를 통합하기
  모니터링에 동일하게 적용된다 — 클라우드 제공자가 독자가 필요한 것을 제공하지 않으면, 써드파티 제품으로 향후 처리를 위해 해당 경보가 표준 형식(예를 들어, syslog)으로 내보낼 수 있도록 해야 한다.

참고자료

교육

• ObjectSecurity's OpenPMF는 액세스 제어 및 감사를 위해 애플리케이션 보안 정책의 관리를 간편하게 하여 안전한 애플리케이션을 개발하고 운영하며 유지보수하는 데 도움을 준다.
  
  
• 모델 구동형 보안으로의 모범적인 참조는 Access Policies for Middleware에서 찾을 수 있다.
  
  
• developerWorks 클라우드 개발자 참고자료에서는 클라우드 배치를 위한 프로젝트를 개발 중인 애플리케이션 및 서비스 개발자의 경험과 지식을 찾아보고 공유할 수 있다.
  
  
• IBM developerWorks Industry 영역에서 구체적인 산업 분야에 종사하면 관심을 가질 만한 기술 기사, 튜토리얼, 커뮤니티, 위키 및 비즈니스 자원을 찾아보자.
  
  

제품 및 기술

• IBM Smart Business Development and Test on the IBM Cloud에서 사용 가능한 제품 이미지를 확인하자.
  
  

토론

• My developerWorks의 클라우드 컴퓨팅 그룹에 참여하자.
  
  
• My developerWorks에 있는 뛰어난 클라우드 블로그를 모두 읽어보자.
  
  
• Model Driven Security 블로그 커뮤니티 포럼에서 Model Driven Security, Model Driven Architecture Security 및 안전한 MDA와 관련된 최신 소식을 읽고 논의하자.
  
  
• 연결, 공유 및 협업을 위한 전문가 네트워크이자 통합 커뮤니티 도구 세트인 developerWorks 커뮤니티에 참여하자.
  
  

필자소개

Ulrich Lang 박사는 ObjectSecurity의 공동 창립자이자 CEO이다. ObjectSecurity의 OpenPMF 제품은 자동화를 통해 애플리케이션 보안을 관리 가능하게 만든다. Ulrich는 모델 구동형 보안, 보안 정책, 클라우드/SOA/미들웨어/애플리케이션 보안에 대해 유명한 사상 리더, 저자 및 연사이자, 정보 보안 분야에서 15년 이상의 경력을 지니고 있다. 그는 1997년에 Royal Holloway College (University of London)에서 Information Security 분야에서 우수한 성적으로 석사 학위를 마친 후에 2003년에 미들웨어 보안의 개념적인 면에서 University of Cambridge Computer Laboratory(Security Group)에서 박사 학위를 받았다.

아티클 순위

의견

위로

목차

• 클라우드 애플리케이션 보안 자동화
• 애플리케이션 보안 정책 자동화의 도전과제
• 모델 구동형 보안 컴포넌트
• 클라우드 애플리케이션 보안 정책 자동화 달성하기
• 사례 연구
• 결론
• 참고자료
• 필자소개
• 의견