次の方法で共有

Identity as a Service プラットフォームの使用

  • [アーティクル]

ほぼすべてのクラウド アプリケーションが、ユーザー ID を使用する必要があります。 ID は、ゼロ トラストなどの最新のセキュリティ プラクティスの基盤であり、アプリケーションのユーザー ID はソリューションのアーキテクチャの重要な部分です。

ほとんどのソリューションに対して、独自に構築または運用するのではなく、専門のプロバイダーによってホストおよび管理される ID ソリューションである Identity as a Service (IDaaS) プラットフォームを使用することが強く推奨されます。 この記事では、独自の ID システムを構築または実行する場合の課題について説明します。

推奨事項

重要

Microsoft Entra ID、Azure AD B2C、または他の同様のシステムなどの IDaaS を使用すると、この記事で説明されている多くの問題を軽減できます。 可能な限り、この方法をお勧めします。

ソリューションの要件により、ご自分でホストして実行するフレームワークまたは既製の ID ソリューションを使用するようになる可能性があります。 事前構築済みの ID プラットフォームを使用すると、この記事で説明されている問題の一部が軽減されますが、そのようなソリューションを使用してこれらの問題の多くを処理することは、ユーザーの責任です。

ゼロから構築する ID システムの使用は避けてください。

資格情報の保存を避ける

独自の ID システムを実行する場合は、資格情報のデータベースを保存する必要があります。

資格情報をクリア テキストに保存したり、暗号化されたデータとして保存したりしないでください。 代わりに、資格情報を暗号化的にハッシュし、ソルト化してから保存することを検討してください。これにより、攻撃が困難になります。 ただし、ハッシュされ、ソルト化された資格情報であっても、いくつかの種類の攻撃に対しては脆弱です。

個々の資格情報を保護する方法に関係なく、資格情報のデータベースを維持すると、攻撃の対象になります。 近年、大規模と小規模の両方の組織が、攻撃の対象となる資格情報データベースを持っていることが示されています。

資格情報ストレージは、資産ではなく負債であると考えてください。 IDaaS を使用すると、資格情報ストレージの問題を、資格情報の安全な管理に時間とリソースを投資できる専門家にアウトソーシングできます。

ID とフェデレーションのプロトコルを実装する

最新の ID プロトコルは複雑です。 業界の専門家は、実際の攻撃と脆弱性を確実に軽減するために、OAuth 2、OpenID Connect、その他のプロトコルを設計しています。 また、プロトコルは、テクノロジ、攻撃戦略、ユーザーの期待の変化に適応するように進化しています。 プロトコルとその使用方法に関する専門知識を持つ ID スペシャリストは、これらのプロトコルに従うシステムを実装および検証するのに最適な立場にあります。 プロトコルとプラットフォームの詳細については、「Microsoft ID プラットフォームにおける OAuth 2.0 と OpenID Connect (OIDC)」を参照してください。

ID システムのフェデレーションも一般的です。 ID フェデレーション プロトコルは、確立、管理、保守が複雑であり、専門的な知識と経験が必要です。 IDaaS プロバイダーは、通常、ユーザーが使用できるように製品のフェデレーション機能を提供します。 フェデレーションの詳細については、「フェデレーション ID パターン」を参照してください。

最新の ID 機能を採用する

ユーザーは、ID システムに次のようなさまざまな高度な機能があることを期待しています。

  • パスワードレス認証: ユーザーが資格情報を入力する必要のない、セキュリティで保護された方法を使用してサインインします。 パスキーは、パスワードレス認証テクノロジの例です。

  • シングル サインオン (SSO): ユーザーが雇用主、学校、または別の組織の ID を使用してサインインできるようにします。

  • 多要素認証 (MFA): ユーザーに、複数の方法で自分自身を認証することを求めます。 たとえば、ユーザーは、パスワードを使用して、さらにモバイル デバイス上の認証アプリやメールで送信されるコードも使用してサインインすることを求められます。

  • 監査: 成功、失敗、中止されたサインイン試行など、ID プラットフォームで発生するすべてのイベントが追跡されます。 後でサインイン試行のフォレンジック検査を行うには、これらの詳細なログが必要です。

  • 条件付きアクセス: さまざまな要因に基づいたサインインの試行に関するリスク プロファイルが作成されます。 要素には、ユーザーの ID、サインイン試行の場所、以前のサインイン アクティビティ、ユーザーがアクセスしようとしているデータまたはアプリケーションの機密性が含まれる場合があります。

  • Just-In-Time アクセス制御: 承認プロセスに基づいてユーザーに一時的にサインインを許可し、その後、承認が自動的に削除されます。

ビジネス ソリューションの一部として ID コンポーネントをご自分で構築している場合、これらの機能の実装と保守に関連する作業を正当化できる可能性はほとんどありません。 これらの機能の一部には、MFA コードを送信するためのメッセージング プロバイダーとの統合や、監査ログを保存して十分な期間保持するといった、追加の作業も必要です。

IDaaS プラットフォームでは、受信するサインイン要求の量に基づいて強化されたセキュリティ機能のセットを提供することもできます。 たとえば、次の機能は、単一の ID プラットフォームを使用する多数の顧客がいる場合に最適です。

  • ボットネットからのサインイン試行など、危険なサインイン イベントの検出
  • ユーザーのアクティビティ間のあり得ない移動の検出
  • 他のユーザーが頻繁に使用するパスワードなど、侵害のリスクが高まる原因となる、共通の資格情報の検出
  • 機械学習手法を使用してサインイン試行を有効または無効として分類する
  • 漏洩した資格情報とそれらの悪用を防止するため、いわゆる "闇サイト" の監視
  • 脅威の状況と攻撃者が使用する最新の攻撃ベクトルの継続的な監視

独自の ID システムを構築または実行する場合、これらの機能を利用することはできません。

信頼できる高パフォーマンスの ID システムを使用する

ID システムは最新のクラウド アプリケーションの重要な部分であるため、信頼性できるものである必要があります。 ID システムが使用できない場合は、ソリューションの残りの部分が影響を受け、機能低下の状態で動作するか、まったく動作しない可能性があります。 IDaaS をサービス レベル アグリーメントと共に使用することで、ID システムが必要なときに引き続き機能するという確信を高めることができます。 たとえば、Microsoft Entra ID では、Basic と Premium のサービス レベルのアップタイムの SLA が提供されており、これによりサインインとトークン発行の両方のプロセスがカバーされます。 詳細については、「Online Services のサービス レベル アグリーメント (SLA)」を参照してください。

同様に、ID システムは、適切に機能し、システムで発生する可能性のある拡張レベルに合わせてスケーリングできる必要があります。 アプリケーション アーキテクチャによっては、すべての要求で ID システムとの対話が必要になる場合があり、パフォーマンスの問題がユーザーに明らかになる可能性があります。 IDaaS プロバイダーは、大規模なユーザー負荷に対応するためにプラットフォームをスケーリングするよう奨励されます。 これらは、さまざまな形式の攻撃によって生成されたトラフィックを含む、大量のトラフィックを吸収するように設計されています。

セキュリティをテストし、厳密な制御を適用する

ID システムを実行する場合、それを安全に保つ責任はユーザーにあります。 実装を検討する必要があるコントロールの例を次に示します。

  • 特殊な専門知識が必要な定期的な侵入テスト。
  • システムへのアクセス権を持つ従業員やその他の人の審査。
  • すべての変更をエキスパートがレビューして、ソリューションへのすべての変更を厳密に制御する。

これらのコントロールは、多くの場合、コストがかかり、実装が困難です。

クラウドネイティブのセキュリティ コントロールを使用する

ソリューションの ID プロバイダーとして Microsoft Entra ID を使用する場合は、Azure リソースのマネージド ID などのクラウドネイティブのセキュリティ機能を利用できます。

別の ID プラットフォームを使用する場合は、アプリケーションでマネージド ID やその他の Microsoft Entra 機能を利用すると同時に、独自の ID プラットフォームと統合する方法を検討する必要があります。

中心的価値を重視する

セキュリティで保護され、信頼性が高く、応答性の高い ID プラットフォームを維持することは、コストがかかり複雑です。 ほとんどの場合、ID システムはソリューションに価値を付加したり、競合他社との差別化を図ったりするコンポーネントではありません。 専門家によって構築されたシステムに ID 要件をアウトソーシングすることをお勧めします。 そうすることで、顧客にビジネス価値を付加するソリューションのコンポーネントの設計と構築に集中できます。

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパル作成者:

  • John Downs | プリンシパル ソフトウェア エンジニア

その他の共同作成者:

  • Jelle Druyts | FastTrack for Azure のプリンシパル カスタマー エンジニア
  • LaBrina Loving | FastTrack for Azure のプリンシパル カスタマー エンジニアリング マネージャー
  • Gary Moore | プログラマー/ライター
  • Arsen Vladimirskiy | FastTrack for Azure のプリンシパル カスタマー エンジニア

パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次のステップ