IAM IDENTITY AND ACCESS MANAGEMEN

【セキュリティ】AWS Cognito/Google Identity/Azure AD B2C/Auth0結局の認証サービス(IDaaS/IAM)はどう言った基準で採用すれば良いのかまとめてみました。

投稿日: カテゴリー: セキュリティ
Pocket

IAMが適切に設計されていれば大半のセキュリティ問題は解決する

アプリケーション層のセキュリティが侵害される場合、意図しないコマンドの実行による侵害か、IAM(Identity and Access Management)つまり、アクセス権限管理の侵害かで大半が占められます。
ここには退職社員が技術情報を持ち出したり、派遣や委託社員が機微情報を持ち出すような故意の侵害から、意図せずデータを破壊できてしまった過失なども含まれます。
IAMを適切に設計することで広範囲のセキュリティの侵害や脆弱性の発生を低減することができると言えます。
そして、そのIAM(Identity and Access Management)とSaaS(Service as a Service)を合わせた言葉がIDaaSです。
XaaSがまた増えてしまったかと言った感じでしょうがアカウント管理、認証、アクセス管理を統括する仕組みをまとめてサービスとして提供しているということです。

最近の認証周りの動向を知りましょう

IDaaSには膨大な機能が提供されていいますが、それらは現代のあらゆる動向を捉えようとした結果です。ごく一例ですが最近の認証周りのトピックを紹介します。

流出リストによる攻撃により回数によるアカウントロックの効果が薄れているCredential Stuffing Attack

リスト型攻撃などで他社から流出した ID とパスワードで攻撃です。悪⽤された可能性のあるアカウントに警告する機能が必要です。
ログイン時の応答差異があるとアカウントリストのとの突合が行われ攻撃のきっかけになり得るため、これまで以上に認証時の応答差異により登録情報を供与する脆弱性を潰しておくことをお勧めします。

Sign In with Apple

サードパーティのログインサービス、もしくは ソーシャルログインサービス( Facebook ログイン、Goole サインイン、Twitter サインイン、Linked-In サインイン、Amazon ログイン、WeChat ログインなど)のみを使ってユーザの設定、プライマリアカウントの認証を行うアプリは、Sign in with Apple も提供しなくてはなりません。
自社独自のサインアップ、サインインシステムのみを使用している場合はSign in with Apple は必要ないそうですが、いまどきソーシャルログインは当たり前でしょうと手を出すとSign In with Appleを実装しなければなりません。iOSアプリはアップルの商品であってその会社のものではないことを忘れてはなりません。ユーザにとっては都度メールアドレスやパスワードを設定することなく、パスワード / TouchID / FaceIDで新規登録やログインができるようになり、Appleが自動生成したメールアドレスを使うことでAppleIDのメールアドレスをアプリに知られないようにすることも可能です。(アプリに登録する際に利用するメールアドレスの匿名化)
公式にサンプルコードと解説がありそこまで手間取ることはないでしょう。

AWS Cognito/GCP Firebase/Auth0の概要

膨大な機能があるので違いだけに着目します。基準ごとに比較してまとめると以下の通りになります。

Google IdentityおよびAzure Active Directory B2CはOIDC準拠のエンドポイントを提供していないため、開発者はサインイン用のUIを実装し、
Firebase SDKの助けを借りて自分でサインアップする必要があります。
Google Identityはアダプティブ認証 (異常検知)も提供していないため、必要であれば自前で実装する必要があります。

比較基準 AWS Cognito Google Identity Azure AD B2C Auth0
アカウントのロックアウト △仕様公開なし※ ○時間解除型

(Firebase Auth)

アダプティブ認証 (異常検知) ○Cognitoにある ×別途実装が必要
OIDC Discovery Endpoint ○IAMにある ×別途実装が必要 ×別途実装が必要 ○有償
Silent Refresh ×別途実装が必要
PKCEへの対応 ×別途実装が必要 ×別途実装が必要
OIDC Discovery Endpoint ○ユーザプールにある ×別途実装が必要 ×別途実装が必要
SLA(⽉間稼働率) 99.9 % FBなし/GI 99.95% 99.9 % 99.9 %

※1 ロックされる具体的な条件や期間については内部仕様のため公開していない

ロギングやモニタリングに関してはどのIDaaSも提供しています。

CognitoやFirebase、Azure AD、Auth0自体あまりよくご存知でない方向けに簡単に要点だけまとめました。

Amazon Cognito

ユーザープール・ID プール・Syncの3つの総称です。

ユーザープール 識別→認証

Amazon Cognito のユーザーディレクトリの役割を持っており、ユーザーの認証を管理し、JWTを発⾏します。

ID プール 認証→認可

ユーザーが⼀意になる ID を作成して、⼀時的な AWS 認証情報をもとに AWS のストレージなどのリソースに直接アクセスできます。

Cognito Sync

1⼈のユーザーデータを複数のデバイスで同期するような⽬的で利⽤できます。

AWS Amplify Authentication

AWS が提供するオープンソースの開発プラットフォームで、バックエンドはAWSが提供するサービスを組み合わせて⾃動構築されます。
Authentication 機能にはは Cognito の機能を利⽤しています。

Google Identity

Firebase Authentication

Firebaseはスマホアプリを作成する際のMBaaSで利用がありそちらの印象が強い方も多いのではないでしょうか。Google製のIDaaSです。マルチテナント機能の導入がCognitoに比べ楽でSAML が導入できる点はアドバンテージです。

Google Identity Platform

Identity Platform は Firebase Authentication を利⽤しています。
AWS AmplifyにおけるAmazon Cognitoの関係に似ています。

Azure Active Directory B2C

Microsoft の Azure が提供するIDaaSです。ロケーションは日本があります。Azure ADの略称で呼ばれ日本企業のクラウド利用率をこれを換算している感がありあます。

Auth0

Auth0はAWS上で動いている故、上乗せになっている分価格面では少し他に比べ高めです。(TwilioもAWS上にあり同じ立場)

専門サービスというだけあり、アカウント連携の豊富さや認証周りの準拠数は圧倒的なので、その辺りが採用の是非を決めるかと考えられます。

以上です。参考になりましたら幸いです。