Analyst Chat 276 (JA)

• Matthias Reinwarth
  • KuppingerCole Analyst Chatへようこそ。ホストを務めます、KuppingerCole AnalystsのAnalyst and Advisor、Matthias Reinwarthです。
  • 本日のゲストはWarwick Ashford。今日の会話をとても楽しみにしています。彼はKuppingerCole AnalystsのSenior Analystで、今回はあなたが書いたブログ記事、テーマはIPSIE——この言葉、僕は好きなんですよ——について話したいと思います。ようこそ、Warwick。
• Warwick Ashford
  • ありがとう、Matthias。
• Matthias Reinwarth
  • 来てくれてうれしいです。この話題はここ数週間で僕のところに2回入ってきました。
  • あなたのブログ記事を見ましたが、standardというより、実際にはprofileの集合として扱っていましたよね。
  • それから数週間前にミュンヘンで開催されたIdentity Fabric Impact DayでDick Hardtの講演もありました。彼はIPSIEのworking groupのchairの一人です。
  • ここまでで3回か4回IPSIEと言いましたが——実際に何を解決するのかに入る前に、IPSIEとは何ですか？ IPSIEは何を意味するんでしょう？ acronymとしては何ですか？
• Warwick Ashford
  • そうですね、いいacronymですよね。Dick Hardtのプレゼンもすごく良くて、「IPSIE… ‘oopsie’は少なめで」みたいな冗談を言っていたと思います、そんな感じの。
  • acronymとしては、構成要素を覚えるのが実は結構難しいんですけど、素晴らしいinitiativeだと思います。
  • Interoperability Profiling for Secure Identity in the Enterpriseの略です。なので、これが何を意味するかは後ほどもう少し掘り下げられます。
• Matthias Reinwarth
  • その通り。
  • あなたのブログ記事を読み始めると——本当におすすめです。subscriptionなしで私たちのサイトで読めます。サイトでWarwickを検索してもいいし、IPSIEで検索する方が簡単かもしれません。あまり頻出しない言葉なので。——冒頭で「identityはいまでもmodern enterprise cybersecurityにおける最大級のvulnerabilityの一つだ」と書いています。
  • これは明らかに正しいですが、SaaSの採用が増えることでさらに進んでいます。なぜそうなるのでしょう？
• Warwick Ashford
  • まず、identityが主要なattack vectorだと言って差し支えないと思います。多くのcyber attackは今でも何らかの形でcompromised credentialsを伴います。盗まれたり、その他の方法で悪用されたりですね。
  • これは、他のsecurity改善が進んでもauthenticationとauthorizationが依然としてweak pointであることを示しています。
  • そしておっしゃる通り、SaaS applicationの増加は、identity systemの数を事実上増やしました。それぞれがsession managementやprovisioningについて独自のロジックを持っています。
  • これがcomplexityとmisconfigurationの可能性を高めます。そしてこの2つがsecurityの敵であることはよく知られています。僕らは「complexityはsecurityの敵」だとどれだけ長く言い続けてきたでしょう？
  • organizationがcloud-first environmentへ移行するにつれて、fragmented identity architectureはpolicyの一貫したenforcementを非常に難しくします。
  • その結果、identity sprawlや不十分なlifecycle governanceに起因するriskが増幅されます。
• Matthias Reinwarth
  • なるほど。私たちは「identity fabric」という概念をずっと提唱しています。視聴者の中には、私たちから1回や2回聞いたことがある方もいると思います。
  • でも要するに、片方にはidentityの適切なadministration——これはIGAの部分——があり、もう片方にはaccount-carrying system、例えばActive DirectoryやEntra ID、そしてあなたが言ったようなSaaS applicationにおけるidentityの利用があります。
  • これは問題への解決策になるはずです。でもあなたが言ったように、cloudでもon-premでもaccount storeが増えるほどcomplexityは上がり、fragmentationが起きます。
  • そしてfragmentationは、inconsistent standard、inconsistent profile、identityの扱い方の不一致、MFAの使い方の違い、なども意味します。
  • では、このfragmentationによって他にどんな具体的な問題が起こるのでしょう？ すでに高いレベルでは触れていますが、もう少し深掘りできますか？
• Warwick Ashford
  • あなたも触れていましたが、developerはintegration challengeに直面します。なぜなら各SaaS vendorが、SAML、OpenID Connect、SCIMのようなcommon protocolを、少しずつ違うversionや解釈で使っているからです。
  • その結果、同じようなcustom integration作業を何度も繰り返すことになり、しかもerror-proneです。これをアプリごとに行う必要があります。
  • security teamはconsistent access controlとprovisioningを維持するのが難しくなり、その結果、orphaned account、弱いsession management、system全体をまたいだvisibility不足などが起きます。
  • つまりfragmentationはoperational overhead、complianceの不確実性、そして最終的には、enterprise policyがすべてのSaaS applicationで正しくenforceされているというtrustの欠如につながります。
• Matthias Reinwarth
  • なるほど。これは明確なproblem statementです。解くべきものがあります。
  • ではここで登場するのがIPSIE——Interoperability Profiling for Secure Identity in the Enterpriseです。背後にはworking groupがあり、real-life problemに取り組んでいます。OpenID Foundationのworking groupでもあるので、visibilityもindustryからのbackingもあります。
  • このIPSIE initiativeはどうやってcomplexityを下げ、interoperabilityを改善し、あなたが挙げたような「standardの解釈のばらつき」を解決しようとしているのでしょう？
• Warwick Ashford
  • はい、missionは、enterprise identity ecosystemに対して統一されたinteroperability layerを作ることです。profileを使って、既存のstandardを「具体的にどう実装すべきか」を正確に定義し、それをconsistentかつsecureにします。
  • これらの、いわゆるopinionated profileは、standardにあるoptionalな機能を取り除いて、secureでinteroperableなdefaultを強制します。
  • さらにIPSIEは、SSO、account lifecycle、entitlementなどの領域に対して測定可能なmaturity levelも導入します。これによりenterpriseはimplementation qualityを評価するframeworkを得られます。
  • また、conformance testingやcertificationを可能にすることで、IPSIEはvendorをまたいでuniformなsecurityとinteroperabilityのcriteriaを満たしていると信頼できるapplicationを実現できます。
  • そしてあなたが言ったように、さまざまなorganizationに支えられている点は、FIDOが成功した理由とも似ています。単独のinitiativeではなく、industryによって推進されたからです。
• Matthias Reinwarth
  • IPSIEが提供するmaturity levelやprofile——session lifecycle management、account lifecycle managementの周り——enterprise implementationにとってのpractical implicationは何でしょう？ 現実の場面でどう使えますか？
• Warwick Ashford
  • identity managementのmaturityの各段階で、secureなimplementationがどういう姿なのかを示す、明確なroadmapを作ります。
  • 例えばsession lifecycleを見ると、level 1はNISTのFederation Assurance Level 2（FAL2）のrequirementに整合します。MFAの強制や、厳格なsession lifetimeの定義などを行い、露出を減らします。
  • より高いsession lifecycle levelでは、applicationとidentity providerの間でsession stateをcommunicateするようなcapabilityが追加されます。
  • 同様にaccount lifecycle levelも、AL1の基本的なuser provisioningから始まり、AL3ではroleやentitlementのsynchronizationまでautomationを拡張します。
  • これによりleast privilegeを支え、よりdynamicなaccess governanceが可能になります。
• Matthias Reinwarth
  • なるほど。僕はIPSIEが完全に理にかなっている点がよく分かります。なぜなら、configurationをどうするかが明確でないと、常に解釈の余地が残ってしまうからです。
  • IPSIEはそれがありません。「こうやってやる」と明示し、そうすれば特定のlevelでIPSIEにcompliantになります。すると、system同士がより近づき、全体としてよりsecureになります。
  • あなたが挙げた（criticismというより）shortcomingの一つは、現時点のIPSIEがhumanに強くフォーカスしていて、employee / workforce中心だという点でした。
  • non-human identityがニュースで頻繁に取り上げられる中で、これはlimitationになりますか？
• Warwick Ashford
  • はい、間違いなく。IPSIEは現実に存在し続ける課題に対処しています。選択肢を取り除き、secure defaultを強制することで、弱い、または一貫性のないimplementationの可能性を減らします。これはinteroperabilityのために非常に重要です。
  • ただ、おっしゃる通りIPSIEのscopeは現状、workforce userとSaaS applicationに限定されています。service account、API、machine credentialのようなものはカバーしていません。
  • しかしそれらは大きく、急速に拡大しているattack surfaceです。non-human identityは自動化されたenvironmentの中心になりつつあります。それを除外すると、access controlやlifecycle managementにおけるblind spotが残ります。
  • そして、non-human entityを含むようにIPSIEのframeworkが拡張されない限り、enterpriseは別のgovernance solutionが必要になり、その結果fragmentationのriskを開くことになります。これはあまり良い考えではありません。
• Matthias Reinwarth
  • なるほど。ただ、risk-based approachで考えると——僕はずっとそれを説いてきましたが——あなたが最初に挙げた大きなriskはpeople risk、workforce risk、enterprise user、つまりhuman riskです。だからそこから始めるのは確かに良いアプローチです。とはいえ、今後も進化していくeffortですよね。
  • organizationは、いまあるprofileやstandardをどう活用してidentity governance全体を改善できますか？ もしかするとnon-human identityにもつなげられるでしょうか？
• Warwick Ashford
  • これは「様子見で待つより、使えるものは使った方がいい」というケースだと思います。利用可能になり次第、organizationは標準化されたprofileをsecureなSaaS integrationのfoundationとして使い始めるべきです。
  • その上で、machine identityに対してはlifecycleやsecrets management toolなどで追加のcontrolを重ねられます。
  • さらに、IPSIE compliantなSaaS identityを、より大きなidentity fabricに統合すれば、humanとnon-human identityの両方でconsistentなpolicy enforcementを維持する助けになります。
  • そしてenterpriseは、automated discovery、least privilege enforcement、continuous monitoringといったgovernance mechanismでIPSIEを補完し、統一されたzero trust identity modelを実現すべきです。
• Matthias Reinwarth
  • つまり、全体のidentity fabric modelに完璧にフィットするわけですね。
  • そして、それがあなたが書いた理由であり、僕らが話している理由でもあります。なぜなら、まず新しいstandardやprotocolを導入しないといけない、というものではないからです。
  • そうではなく、すでにあるものを、よりconsistentに、そして最終的にはよりsecureに実装するためのguidanceを与えるものです。
  • もちろん、working groupへの貢献者や、vendorが実装したり自社frameworkへ統合したりするサポートは必要で、まだ道のりはあります。でも、それは人々が実際に使うことの妨げにはならないですよね？
• Warwick Ashford
  • ええ、同意します。IPSIEは実際のprogressを示していると思います。
• Matthias Reinwarth
  • そうですね。私たちはいつも通り、この領域を注視していきます。あなたのブログ記事で取り上げ、イベントではDick Hardtが登壇し、そして今日こうして話しました。
  • もしあなたがIPSIEを最初に見てみたいと思うなら、Warwickのブログ記事はsourcesへのlinkも含めて良い出発点です。
  • 直接行きたいなら、Googleでも、好きなsearch engineでも見つけられるはずです。
  • profileはそれほどtechnicalではなく、読みやすいですし、すぐにbenefitを得られてsecurity postureを改善できます。
  • 今日はここまで。私たちはこの領域を追い続けます。進化していくはずですし、そうでなければなりません。
  • まだ完全に完成しているわけではなく、すべてのlevelが完全に定義されているわけでもありません。でも、現時点であるものは使える状態だと思います。
• Warwick Ashford
  • はい、その通りです。
• Matthias Reinwarth
  • 改めて、今日はゲストとして来てくれてありがとう、Warwick。楽しかったです。
  • それに、「課題があって、誰かが解決しようと試みて、最初のアプローチが出てきて、それを使える」——そういうものがあるのは本当に良いことですよね？
  • ゲストとして来てくれてありがとう。また近いうちに別の回でもお迎えできるのを楽しみにしています。
• Warwick Ashford
  • ありがとう、Matthias。じゃあね。

• [MUSIC]