コンシューマー向けIDサービスとAkamai Identity Cloud
弊社のCustomer Identity PlatformであるAkamai Identity Cloudは、コンシューマー向けIDサービスの標準であるOAuth/Open ID Connectに早期から準拠しており、MobileからWeb Applicationまで幅広いユースケースで認証〜認可サービスをご提供しています。この記事ではコンシューマー向けIDサービスが誕生した背景から振り返り、多くのコンシューマーから求められているデジタル体験について考察します。
Enterprise Directoryの限界とSAML
1990年代中盤頃、Active DirectoryやLDAPなど、複数のApplicationで共有できるEnterprise Directoryにユーザーのクレデンシャルを一元管理する手法が一般化され始めました。Directory Serviceは個々のApplication毎にID Storeを持つ必要が無く管理性も高い反面、社内での利用に限定される限界がありました。このEnterprise Directoryの限界を打破するために、2000年中盤頃に当時の主要企業が協議してDirectory Service間の信頼を確立するSAML(Security Assertion Markup Language)が誕生しました。SAMLで企業間の信頼を確立することで、自社内のDirectory Serviceのクレデンシャルで相手側のApplicationにSSOすることが可能になりました。この考え方を、企業間の利用だけでなく一般コンシューマーの世界でも利用できないか?といった動きが出始めました。これがコンシューマー向けIDサービス誕生のきっかけです。
Softwareアーキテクチャの変遷 - MonolithicからMicroserviceへ
"全ての企業がSoftware企業になる"と言われる昨今、あらゆる企業が日々革新的なSoftwareを開発して市場に投入されていると思います。ニーズ把握〜設計・開発〜市場投入までのサイクルが短くSoftwareのリリース頻度が高い企業ほど市場獲得のチャンスは高く、多くの企業でSoftware Life Cycleの高速化の取り組みが始まっていると思います。従来の全ての機能を1つのSoftwareで持つMonolithic型のSoftwareは新しい機能を追加してから市場に投入するまでの時間が長くなるため、機能毎にSoftwareをAPIとして分割するMicroservice型のSoftwareが台頭してきました。
Password共有の問題
Microservice型のSoftwareが台頭し市場投入サイクルの高速化は実現できましたが、APIのPasswordを共有しなければならない新たな問題が顕在化し始めました。フロントエンドのApplicationからバックエンドのAPIを呼び出すシーンを考えてみます。
User ID/Password -> Application ID/Password <- Attacker -> ID/Password -> API
- UserはApplicationにアクセスしてAPIを呼び出すために、APIのID/PasswordをApplicationに渡します。
- Application側でID/Passwordを再利用できるようにストレージに保管します。
- AttackerがID/Passwordを入手して不正にAPIにアクセスして機密情報を取得します。
2でApplicationはUserから受け取ったID/Passwordを機密性の低いストレージに保管したことで、悪意のあるAttackerに盗まれてしまい、本来のUser以外はアクセスすべきではない機密性の高い情報が外部に漏れてしまいました。
OAuth — 権限委譲型の認可フレームワークの誕生
SAMLの考え方を一般コンシューマーの世界でも利用できないか?といった動きと同時に、Softwareアーキテクチャが見直されMicroservice型のサービスが台頭し、一般コンシューマーは様々なサービスをAPI経由で利用できるようになりました。そして先に触れたPassword共有の問題を解決するために、Applicationに特定のことだけを認可する仕組みであるOAuthが誕生しAkamai Identity CloudのようなAuthorization Serverと呼ばれる新しいEntityが誕生しました。先程と同様にフロントエンドのApplicationからバックエンドのAPIを呼び出すシーンを考えてみます。
User -> Application -> Authorization Server -> API
User ID/Password -> Authorization Server
Application <- Access Token Authorization Server
Application Access Token -> API
- ApplicationはAPIを呼び出すためにAuthorization ServerにTokenを払い出して欲しいと要求します。
- Authorization ServerはUserにID/Passwordの入力を要求しUserは各々を入力します。
- Authorization ServerはID/Passwordを検証してTokenをApplicationに払い出します。
- ApplicationはTokenを利用してAPIを呼び出します。
OAuthの誕生によりUserのID/PasswordはAuthorization Serverで一元管理され、予め定められた認可情報に基づきTokenが払い出され安全にAPIにアクセスすることが可能になりました。またTokenには認可された操作のみが規定されているため、Applicationに必要以上に権限を渡すことがなく不慮の情報漏えいも未然に防ぐことが可能です。
Open ID Connect — OAuthに認証の要素を追加
OAuthによってPassword共有も問題を回避して必要最低限の処理だけ認可される仕組みはできましたが、Access Tokenには"誰が認可されたのか?"の情報が含まれていないため新たな課題が露呈されました。そこで、再度主要企業が中心となり協議がなされ認証についてもカバーしたOpen ID Connectが誕生し、Access Tokenと同時に認証情報を含むID TokenがApplicationに払い出されるようになりました。ApplicationはID Tokenを検証して、一度認証されたユーザーについてはAuthorization Serverに再認証することなく認証済みと見なしたり、ID Tokenに含まれるユーザー属性を取り出して表示したりできるようになりました。
Akamai Identity Cloudとは?
Akamai Identity Cloudは弊社のCustomer Identity Platformで、2010年頃から先に触れたコンシューマー向けIDサービスの標準であるOAuth/Open ID Connectに完全準拠しています。Customer Identity Platformは最終的な利用ユーザーが一般コンシューマーであるため、社内で利用されるEnterprise Directoryとは求められる要件もまったく異なります。
求められること#1 — Privacy
SAMLが"企業間の信頼"により成り立つフレームワークであることと同様に、コンシューマーの世界でもサービスを提供する企業側とコンシューマの間の"信頼"が不可欠であると考えます。コンシューマーの個人情報の使用目的や条件などを示した文章と、同意する/しないの意思表示ができる場面が一元的に提供できれば、コンシューマーにとっては信頼できて使いやすいサービスになるかと思います。Akamai Identity Cloudでは世界9カ所にID Storeを置くことで、企業が管理するコンシューマの属性情報を各地域の規制に合わせて分散管理することが可能です。
求められること#2 — Protection
これまでコンシューマーの個人情報へのアクセス制御はRole Based Access Control (RBAC) と呼ばれる管理権限レベルによるアクセス制御が主流でしたが、Akamai Identity CloudはRBACより更にきめ細かなユーザー属性レベルで開示する/しないを制御することが可能です。一口に"個人情報"と言っても、重要度は属性により異なります。また、個人情報がネットワーク上で行き来する際やストレージに保管される際の暗号化も必ず求められます。CDNビジネスを20年以上リードしている弊社の対応状況は言わずもがなです。
求められること#3 — Performance
現在市場を席巻しているクラウドサービスは、全てのリクエストをバックエンドのデータセンターで処理する中央集権型のアーキテクチャが主流かと思います。それに対して、弊社は世界中に分散されたCDN Serverで処理するエッジ中心型のアーキテクチャをとっています。これにより、バックエンドのデータセンターリソースの枯渇やネットワークの遅延を回避しながら、快適で安全なデジタル体験をコンシューマーに提供することが可能です。
