타스크: 보안 패턴 식별
시스템의 초기 아키텍처 중에 보안 설계자는 시스템에서 필요한 보안 레벨을 확인하는 핵심 보안 패턴을 식별하고 선택해야 합니다.
원칙: 분석 및 디자인
목적

사전 정의된 패턴에서 선택하여 보안 솔루션의 개발에 필요한 핵심 메커니즘을 제공합니다.

관계
기본 설명

이 타스크의 목적은 설계자가 보안 요구사항 및 정책에 대한 아키텍처 요소를 첨부하는 데 적합한 상위 레벨 보안 패턴을 식별하도록 돕는 것입니다. 그 다음 이 패턴은 다운스트림 디자인 및 구현 타스크에 의해 특정 기술 및 플랫폼 선택사항에 적합한 세부적인 패턴으로 구분됩니다.

보안 패턴에 대한 자세한 정보는 개념: 보안 패턴을 참조하십시오.

단계
보안 요구사항 식별

이 단계 중에 역할: 보안 설계자 는 프로젝트의 상위 레벨 보안 요구사항 및 이 프로젝트의 핵심 아키텍처 요소를 캡처해야 합니다. 이 요구사항은 아티팩트: 소프트웨어 아키텍처 문서 및 아티팩트: 보충 스펙에서 캡처되며 이 요구사항이 솔루션의 아키텍처를 제한하는 경우, 요구사항을 아티팩트: 참조 아키텍처에 포함해야 합니다. 보안 설계자의 역할은 프로젝트의 이해 당사자의 복잡한 요구사항을 도출하여 이해하기 쉬운 형태의 진술 즉, 의도로 수집하는 것입니다.

이 단계에서 이해 당사자의 의도를 중요시하는 이유는 요구사항 수집 세션(가이드라인: 요구사항 워크샵 참조)에서 보안 관련 질문 시 이해 당사자 대부분이 "모든 대상에 보안이 필요합니다."라고 답변하기 때문입니다. 이는 이 질문에 대한 답변이 ""인 모든 대상에 암호화, 감사 등을 수행해야 함을 의미합니다. 여기서 보안 설계자는 이와 같은 결정의 구현, 비용, 복잡도를 설명하고 그룹에서는 아키텍처의 요소와 관련된 패턴에 대해 의미있는 논의를 시작합니다. 이 패턴에서는 보안과 관련된 시스템의 의도를 표현하는 반면 디자인 레벨 패턴에서는 의도를 충족시키는 메커니즘을 표현하고 마지막으로 구현 패턴에서는 의도를 충족시키는 데 사용된 기술을 표현합니다.

신뢰 경계 식별

신뢰는 모든 보안 솔루션의 핵심 사항입니다. 두 관계자에서 특정 신뢰 레벨을 공유하고 있으며 이 레벨 상태가 보안이 필요없는 "완전히 신뢰함" 상태이거나 근거 없는 규칙을 "전혀 신뢰하지 않음" 상태에 있음을 전제로 하기 때문에 보안이 필요합니다.

  1. 신뢰 불필요(맹목적 신뢰): 공용 서비스를 제공하는 제공자가 호출 시스템에 대한 신뢰 문제를 고려할 필요가 없습니다. 호출 시스템에서 아무 내역 없이 ID를 전송하고 요청을 처리할 때 제공자는 해당 ID로 간주할 수 있습니다. 가장 공격을 방지할 수 있는 방법이 없습니다.
  2. 네트워크 구성 기반 신뢰: 소프트웨어 구성이 신뢰를 제공하지 않습니다. 네트워크는 제공자에게 메시지를 전송할 수 있는 시스템의 수를 제한하는 방법으로 가능한 한 분할을 통해 방화벽을 설치한 서브넷으로 구성됩니다. 상황이 악화될 경우, 대상 호출 시스템과 서브넷의 제공자 시스템만 서브넷에 표시되는 경우도 발생할 수 있습니다. VPN을 사용하여 잠재적 호출 시스템을 제한하는 경우도 있습니다.
  3. 하부 구조 기반 신뢰: 하부 구조(예: 전송 프로토콜 ... 가능한 한 MA SSL 또는 SSL + BA)는 신뢰 시스템임을 유효성 검증하기 위해 호출 시스템을 식별하도록 구성됩니다. 웹 서비스(SOAP) 메시지에는 제공자가 요청 처리 시 추정해야 하는 호출자 ID만 있습니다.
  4. 토큰 기반 신뢰: 지점 간 토큰 신뢰 - 호출자 ID를 검증하는 메시지에 토큰이 있으며 이는 신뢰 호출 시스템에서 작성됩니다(예: SAML, LTPA). 써드파티 토큰 신뢰 - 호출자 ID를 검증하는 메시지에 토큰이 있으며 이는 신뢰 써드파티 시스템 KDC/STS에서 작성됩니다(예: SAML, Kerberos).
  5. 토큰 컨텍스트 기반 신뢰: 토큰을 포함하는 서명과 메시지 - 호출자 ID를 검증하는 메시지 및 토큰을 포함하는 신뢰 호출 시스템에서 작성한 메시지에 서명이 있으며 이 서명으로 호출 시스템을 인증합니다. 메시지오 포함된 두 가지 토큰 - 신뢰 호출 시스템을 인증하는 메시지에 있는 토큰과 호출자를 식별하는 토큰 두 가지가 있습니다. 서명과 마찬가지로 두 가지 토큰을 함께 메시지에 바인드하는 특정 메커니즘이 필요합니다.
  6. "신뢰"의 최종 단계는 인증입니다. 증거를 제시하는 모든 토큰에서는 신뢰를 확립하기 위한 추가 메커니즘이 필요 없습니다.

신뢰 영역

대규모 조직의 경우, 엔터프라이즈를 관리 영역으로 세분화하고 여러 신뢰 영역을 확립하는 것이 효율적인 경우가 많습니다. 여러 영역에서 신뢰 관계의 다양한 하위 유형을 확립할 수 있습니다. 두 관계자 중 한 관계자만 일반 사용자와 관계가 있는 경우 신뢰 관계를 확립할 수 있는 몇 가지 방법에 대한 예제는 다음과 같습니다.

  • 직접 신뢰 - 토큰 교환: 신뢰 도메인 1은 일반 사용자를 인증하고 신뢰 도메인 2는 ID 또는 ID 사용을 필요로 합니다. 경우에 따라(예: 개인화만 필요한 경우) 인증이 필요하지 않을 수 있습니다.
  • 직접 신뢰 - 토큰 유효성 검증: 신뢰 도메인 1에서는 새 ID 검증을 작성하며 식별된 사용자를 인증하는 고유한 증거를 제시할 수 있습니다. 신뢰 도메인 2에서는 신뢰 대상(신뢰 도메인 1)에서 이루어지는 검증을 평가하고 사용자 검증 대신 이를 사용합니다.
  • 토큰 서비스 및 ISP: 신뢰 관계는 때로 다양한 관계자 간에 확립되며 사용자 인증은 독립된 서비스 즉, ID 서비스 제공자로 구분됩니다. 이 ID 서비스 제공자는 각각 다양한 수준의 기능성을 갖고 있습니다. 이 제공자들 중 일부는 요청의 대상을 찾고 사용자를 인증할지의 여부를 결정합니다. 또한 현재 토큰을 두 번째 토큰과 교환할지의 여부를 인식하며 이 요청을 적절한 관계자에 경로 지정할 수 있습니다.
  • 간접 신뢰: 관계자가 서로 직접 신뢰 관계가 아니지만 "브로커"에게 교환을 위임하는 써드파티를 공유합니다.
  • 위임: 직접 및 간접 신뢰 관계의 조합을 확립할 수 있습니다.
상위 레벨 보안 패턴 식별

이 타스크에서 식별된 상위 레벨 보안 패턴은 다음과 같습니다. 소프트웨어와 하드웨어 요소에 영향을 주는 보안 요구사항의 영향을 받는 시스템 아키텍쳐의 요소가 이러한 하나 이상의 패턴(아티팩트: 소프트웨어 아키텍처 문서에 문서화)과 연관될 수 있으므로 설계 작업 중에 세분화할 수 있습니다.

ID 및 인증

일반 사용자는 ID(사용자 이름) 및/또는 ID(제목, 역할, 별명)의 세트와 증거(암호)를 갖고 있으며 랩탑 또는 PDA와 같은 클라이언트 시스템에 보존됩니다. 응용프로그램에 대한 ID 식별이 프롬프트될 때 인증을 위해서 사용자는 ID와 응용프로그램에 제시합니다. 응용프로그램이 ID 및 증거의 유효성을 검증하는 경우, 사용자는 "인증"되고 ID는 "인증된 ID"가 됩니다. 응용프로그램에서 비즈니스 로직을 구현하고 보안 정책을 시행하는 경우, ID 데이터/메타데이터 저장소(파일 시스템, 데이터베이스 등)에 해당 데이터/메타데이터를 보존해야 합니다. 웹의 출현과 함께 일반 사용자의 시스템에 응용프로그램 클라이언트 코드가 없어지지만 일반 사용자는 종종 브라우저를 통해 응용프로그램에 액세스하며 네트워크에서는 일반 사용자가 제공한 URI(유니버셜 자원 ID)를 통해 응용프로그램을 찾습니다.

SSO(Single Sign-On)

사용자가 서로 다른 ID 및 증거가 있는 여러 응용프로그램을 갖고 있는 경우, ID 데이터 및 메타데이터를 관리하고 적절한 결정을 내리기가 어렵습니다. 다중 응용프로그램의 복잡도를 줄이기 위해 여러가지 수동 및 자동 기술에서 사용하는 용어가 SSO(Single Sign-On)입니다.

SSO의 솔루션은 클라이언트 기반 또는 서버/서비스 기반이며 응용프로그램에 서로 단단하게 결합되거나 느슨하게 결합될 수 있습니다. 웹 기반 SSO는 브라우저 기반 솔루션을 참조하며 일반적으로 쿠키를 포함합니다. 단단하게 결합된 클라이언트 기반 SSO의 경우, 사용자는 다중 응용프로그램 저장소에서 유지보수되는 다중 ID/암호를 등록하고 동기화해야 합니다. 일부 SSO는 "ID 맵핑"에 따라 결정되며 나머지는 "ID 사용" 또는 "ID 검증"을 제공합니다. 페더레이티드 SSO의 새 이니셔티브로 사용자는 써드파티 ID 서비스 제공자로 등록한 후 사용자 정보를 관리하여 느슨한 결합을 대신할 SSO를 제공합니다. 엔터프라이즈에서 백엔드 SSO에는 ISP 역할을 하는 엔터프라이즈가 포함될 수 있습니다. 백엔드 SSO에는 모든 응용프로그램에 대한 공통 저장소가 포함되며 각 응용프로그램/서버는 재구성되어 로컬 저장소를 사용하지 않습니다. 백엔드 SSO에서는 또한 사용자 정보의 다중 저장소를 유지보수할 수 있으며 관리 프로세스를 이용하여 다중 저장소에 있는 ID 데이터의 동기화를 강제 실행할 수 있습니다. 여러 ID가 서로 관련이 있는 경우, 응용프로그램을 관리 도메인과 연관된 범주로 분리시켜야 하는 경우가 많습니다.

디지털 ID

컴퓨터 기술에 대한 비즈니스와 인간의 의존도가 높아지고 있으며 ID 정보가 점차 증가하는 추세입니다. ID 도용 문제의 심각성을 인식한 정부에서는 ID 정보를 보호하기 위한 비즈니스 요구사항을 법으로 규정하고 있습니다.

디지털 ID 솔루션 - 디지털 ID를 관리하는 데 필요한 두 가지 주요 전략이 있습니다. 한 가지 방법은 "사용자 중심" 전략인데 이는 ID를 적극적으로 보호하는 사용자에게 의존하는 방법입니다. 써드파티 제공자로 "등록"한 후 자신의 ID 데이터 및 메타데이터에 액세스할 권한을 사용자가 신뢰하는 제공자에게 부여하여 ID를 보호합니다. Liberty Alliance에서 공동으로 이 전략을 주도하고 있으나 Apache Foundation에서도 협력의 일환으로 Higgins 이니셔티브를 통해 개방형 소스 개발을 진행 중입니다.

두 번째 방법은 비즈니스 중심 모델인데 이 모델의 비즈니스는 고객, 파트너 및 고용인에게 ID 관리 서비스를 제공합니다. 근본적인 기술은 접근 방식과 관계없이 동일하나 디지털 ID 관리 서비스를 제공하기 위해 관리하고 책임지는 방식이 다릅니다. 비즈니스에서 처리하는 정보의 양은 개인이 처리하는 정보의 양과 다르므로 다양한 요구사항을 바탕으로 합니다. 또한 이 모델에는 비즈니스 역할 기반의 사용자 액세스 관리 및 비즈니스 조건 변경을 위해 고유한 시스템이 있어야 합니다. 즉, 사용자는 다양한 회사에서 일하지만 수행하는 비즈니스는 항상 동일합니다.

권한 부여

컴퓨터 기술에 대한 비즈니스와 인간의 의존도가 점차 높아짐에 따라 자원별로 액세스 권한이 부여된 사용자를 규정하는 규칙이 체계화되었습니다. 응용프로그램 설계 시 정보에 대한 액세스 권한이 있는 사용자는 비즈니스 컨텍스트 정보에 따라 결정됩니다. 또는 응용프로그램을 기준으로 결정되고 개별 미들웨어 세트별로 처리될 수도 있습니다.

메시지 보호

기본 보호 유형에는 두 가지가 있습니다. 한 가지 유형은 전송 중 메시지가 변경되지 않았다는 증거인 무결성 보호이고 나머지는 메시지를 볼 수 있는 권한 부여된 수신자만 확인하도록 응용프로그램을 암호화하는 기밀성입니다. 프로토콜을 통해 메시지를 송신할 때 각 메시지는 디지털로 서명되고 암호화될 수 있습니다. 프로토콜을 통해 보호하는 것을 "지점 간"(예: 네트워크 종료점 간) 프로토콜이라고 합니다.

핵심 고려사항
이 타스크 중 식별된 보안 패턴은 상위 레벨이며 특정 기술 또는 플랫폼에 대한 종속성이 없습니다. 이와 같은 각 패턴은 기술용 패턴과 플랫폼용 패턴에서 번갈아 지원됩니다. 이러한 세부적인 패턴 정의는 프로젝트에서 선택된 기술 및 플랫폼의 구현자가 사용해야 합니다.
자세한 정보
개념