다음을 통해 공유

Identity as a Service 플랫폼 활용

  • 아티클

거의 모든 클라우드 응용 프로그램은 사용자 ID로 작동해야 합니다. ID는 제로 트러스트와 같은 최신 보안 사례의 기반이며 애플리케이션의 사용자 ID는 솔루션 아키텍처의 중요한 부분입니다.

대부분의 솔루션에 대해, 자체적으로 구축하거나 운영하는 대신, 전문 공급자에 의해 호스팅되고 관리되는 ID 솔루션인 IDaaS(Identity as a Service) 플랫폼을 사용하는 것을 강력히 권장합니다. 이 문서에서는 사용자 고유의 ID 시스템을 빌드하거나 실행하는 데 따르는 문제에 대해 설명합니다.

권장 사항

Important

이 문서에서 설명하는 많은 문제를 완화하기 위해 Microsoft Entra ID, Azure AD B2C 또는 기타 유사한 시스템과 같은 IDaaS를 사용할 수 있습니다. 가능한 경우 이 방법을 사용하는 것이 좋습니다.

솔루션 요구 사항에 따라 직접 호스트하고 실행하는 프레임워크 또는 기존 ID 솔루션을 사용할 수 있습니다. 미리 빌드된 ID 플랫폼을 사용하면 이 문서에 설명된 일부 문제가 완화되지만 이러한 문제 중 많은 부분을 처리하는 것은 여전히 그러한 솔루션을 사용하는 사용자의 책임입니다.

처음부터 빌드하는 ID 시스템을 사용하지 않아야 합니다.

자격 증명 저장 금지

사용자 고유의 ID 시스템을 실행하는 경우 자격 증명 데이터베이스를 저장해야 합니다.

자격 증명을 일반 텍스트 또는 암호화된 데이터로 저장해서는 안 됩니다. 대신 자격 증명을 저장하기 전에 암호학적 해싱 및 솔팅을 고려하여 공격하기 더 어렵게 만들 수 있습니다. 그러나 해시 및 솔트 처리된 자격 증명도 여러 유형의 공격에 취약합니다.

개별 자격 증명을 보호하는 방법에 관계없이 자격 증명 데이터베이스를 유지 관리하면 공격의 대상이 됩니다. 최근 몇 년 동안 대규모 조직과 소규모 조직 모두 자격 증명 데이터베이스가 공격 대상이 된 것으로 나타났습니다.

자격 증명 스토리지를 자산이 아닌 부채로 간주합니다. IDaaS를 사용하면 자격 증명을 안전하게 관리하는 데 시간과 리소스를 투자할 수 있는 전문가에게 자격 증명 스토리지 문제를 아웃소싱할 수 있습니다.

ID 및 페더레이션 프로토콜 구현

최신 ID 프로토콜은 복잡합니다. 업계 전문가들은 실제 공격과 취약성을 완화할 수 있도록 OAuth 2, OpenID Connect 및 기타 프로토콜을 설계했습니다. 또한 프로토콜은 기술, 공격 전략 및 사용자 기대치의 변화에 맞게 진화합니다. 프로토콜과 프로토콜 사용 방법에 대한 전문 지식을 갖춘 ID 전문가는 이러한 프로토콜을 따르는 시스템을 구현하고 유효성을 검사할 수 있는 최적의 위치에 있습니다. 프로토콜 및 플랫폼에 대한 자세한 내용은 Microsoft ID 플랫폼의 OAuth 2.0 및 OIDC(OpenID Connect)를 참조하세요.

ID 시스템을 페더레이션하는 것도 일반적입니다. ID 페더레이션 프로토콜은 설정, 관리 및 유지 관리가 복잡하며 전문 지식과 경험이 필요합니다. 일반적으로 IDaaS 공급자는 제품에서 사용할 페더레이션 기능을 제공합니다. 페더레이션 ID 패턴을 참조하여 페더레이션에 대한 자세한 정보를 확인하세요.

최신 ID 기능 채택

사용자는 ID 시스템에 다음과 같은 다양한 고급 기능이 있을 것으로 기대합니다.

  • 암호 없는 인증 - 사용자가 자격 증명을 입력할 필요가 없는 보안 접근 방식을 사용하여 로그인합니다. 암호 키는 암호 없는 인증 기술의 한 예시입니다.

  • SSO(Single Sign-on) - 사용자가 고용주, 학교 또는 다른 조직의 ID를 사용하여 로그인할 수 있습니다.

  • MFA(다단계 인증) - 사용자에게 여러 가지 방법으로 자신을 인증하라는 메시지를 표시합니다. 예를 들어, 사용자는 암호를 사용하여 로그인할 수 있으며 모바일 디바이스에서 인증자 앱을 사용하거나 이메일로 전송된 코드를 사용하여 로그인할 수도 있습니다.

  • 감사 - 성공, 실패 및 중단된 로그인 시도를 포함하여 ID 플랫폼에서 발생하는 모든 이벤트를 추적합니다. 이러한 자세한 로그는 나중에 로그인 시도에 대한 포렌식 검사를 수행하기 위해 필요합니다.

  • 조건부 액세스 - 다양한 요인을 기반으로 하는 로그인 시도에 대한 위험 프로필을 만듭니다. 사용자의 ID, 로그인 시도 위치, 이전 로그인 활동 및 데이터 또는 사용자가 액세스하려고 시도하고 있는 애플리케이션의 민감도가 이러한 요인에 포함될 수 있습니다.

  • Just-In-Time 액세스 제어 - 사용자가 승인 프로세스에 따라 일시적으로 로그인할 수 있도록 허용한 다음, 권한 부여를 자동으로 제거합니다.

비즈니스 솔루션의 일부로 ID 구성 요소를 직접 빌드하는 경우 이러한 기능을 구현하고 유지 관리하는 데 관련된 작업을 정당화할 수 없을 것입니다. 이러한 기능 중 일부는 MFA 코드를 보내기 위한 메시지 공급자와의 통합, 충분한 기간 동안 감사 로그를 저장 및 유지하는 등의 추가 작업이 필요합니다.

IDaaS 플랫폼은 수신하는 로그인 요청의 볼륨을 기반으로 하는 향상된 보안 기능 세트를 제공할 수도 있습니다. 예를 들어, 다음 기능은 단일 ID 플랫폼을 사용하는 고객이 많을 때 가장 잘 작동합니다.

  • 봇네트의 로그인 시도와 같은 위험한 로그인 이벤트 감지
  • 사용자 활동 간에 불가능한 이동 감지
  • 다른 사용자가 자주 사용하는 암호와 같이 손상 위험이 높은 공통 자격 증명 탐지
  • 기계 학습 기술을 사용하여 로그인 시도를 유효하거나 유효하지 않은 것으로 분류
  • 유출된 자격 증명에 대한 소위 다크 웹 모니터링 및 악용 방지
  • 공격자가 사용하는 현재 벡터 및 위협 환경에 대한 지속적인 모니터링

사용자 고유의 ID 시스템을 빌드하거나 실행하는 경우 이러한 기능을 활용할 수 없습니다.

신뢰할 수 있는 고성능 ID 시스템 사용

ID 시스템은 최신 클라우드 응용 프로그램의 핵심 부분이므로 신뢰할 수 있어야 합니다. ID 시스템을 사용할 수 없는 경우 솔루션의 나머지 부분이 영향을 받아 저하된 방식으로 작동하거나 전혀 작동하지 않을 수 있습니다. 서비스 수준 계약과 함께 IDaaS를 사용하면 필요할 때 ID 시스템이 계속 작동할 것이라는 확신을 높일 수 있습니다. 예를 들어, 로그인 및 토큰 발급 프로세스를 모두 다루는 기본 및 프리미엄 서비스 계층의 작동 시간에 대한 SLA를 Microsoft Entra ID가 제공합니다. 자세한 내용은 온라인 서비스에 대한 SLA(서비스 수준 계약)를 참조하세요.

마찬가지로 ID 시스템은 잘 작동해야 하며 시스템이 경험할 수 있는 성장 수준으로 확장할 수 있어야 합니다. 애플리케이션 아키텍처에 따라 모든 요청에 ID 시스템과의 상호 작용이 필요할 수 있으며 모든 성능 문제는 사용자에게 명백합니다. IDaaS 공급자는 플랫폼을 확장하도록 장려되며, 이는 대규모 사용자 로드를 수용하기 위함입니다. 다양한 형태의 공격에 의해 생성된 트래픽을 포함하여 대량의 트래픽을 흡수하도록 설계되었습니다.

보안 테스트 및 엄격한 제어 적용

ID 시스템을 실행하는 경우 보안을 유지하는 것은 사용자의 책임입니다. 구현을 고려해야 하는 제어의 예는 다음과 같습니다.

  • 전문 지식이 필요한 주기적인 침투 테스트.
  • 직원 및 시스템에 액세스할 수 있는 모든 사람을 심사합니다.
  • 전문가가 검토한 모든 변경 사항을 통해 솔루션에 대한 모든 변경 사항을 엄격하게 제어합니다.

이러한 제어는 비용이 많이 들고 구현하기 어려운 경우가 많습니다.

클라우드 네이티브 보안 제어 사용

솔루션의 ID 공급자로 Microsoft Entra ID를 사용하는 경우, 클라우드 네이티브 보안 기능인 Azure 리소스에 대한 관리 ID 등을 사용 가능합니다.

별도의 ID 플랫폼 사용을 선택하는 경우에는 애플리케이션이 관리 ID 및 기타 Microsoft Entra 기능을 사용하는 동시에 자체 ID 플랫폼과 통합하는 방법을 고려해야 합니다.

핵심 가치에 집중

안전하고 안정적이며 응답성이 뛰어난 ID 플랫폼을 유지 관리하는 것은 비용이 많이 들고 복잡합니다. 대부분의 경우 ID 시스템은 솔루션에 가치를 추가하거나 경쟁업체와 차별화하는 구성 요소가 아닙니다. 전문가가 빌드한 시스템에 ID 요구 사항을 아웃소싱하는 것이 좋습니다. 이렇게 하면 고객을 위한 비즈니스 가치를 추가하는 솔루션의 구성 요소를 설계하고 구축하는 데 집중할 수 있습니다.

참가자

Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.

보안 주체 작성자:

  • John Downs | 소프트웨어 수석 엔지니어

기타 기여자:

비공개 LinkedIn 프로필을 보려면 LinkedIn에 로그인하세요.

다음 단계