Architecting Amid Regulations in Finance

0:00:05 エミリー・ウェアマス (Emily Wearmouth): こんにちは。セキュリティビジョナリーポッドキャストへようこそ。ホストのエミリー・ウェアマス (Emily Wearmouth) がお送りします。本日は、ヨーロッパの大手投資銀行でアーキテクチャおよびクラウドを統括するセブ・レアル・ベネット (Seb Leal Bennett) をゲストに迎えてお届けします。彼はこれまでのキャリアを通じて一貫して金融サービス業界に身を置いており、おそらく最も規制が厳しく、リスクが極めて高いテクノロジー環境の最前線であることにおそらくご同意いただけるでしょう。彼はクラウド向けのアーキテクチャ構築、レジリエンス、セキュリティのエキスパートであり、おそらくエラーの許されない環境で手腕を発揮してきました。番組へようこそ、セブ。

0:00:36 セブ・レアル・ベネット (Seb Leal Bennett): 素晴らしいですね。ありがとうございました。

0:00:36 エミリー・ウェアマス (Emily Wearmouth): ご出演いただき光栄です。

0:00:39 セブ・レアル・ベネット (Seb Leal Bennett): 楽しみにしていました。

0:00:40 エミリー・ウェアマス (Emily Wearmouth): 少し踏み込んだ質問になりますが、実のところ、この「規制が非常に厳しい」という点は非常に重要だと考えていますので、早速本題に入らせていただきます。今回ご出演いただけたことを本当に嬉しく思っている理由の1つです。最初に考えておきたいのは、クラウド向けにアーキテクチャを構築する際、どこかに保管されているこうした規制について、実際にどのような意味を持つのかということです。これらが常に念頭に置かれており、それらが課す制約を起点とした上で、その中でどのようなことが可能かを検討するということでしょうか？それとも、正しいと思われるアプローチを自分で設計し、「ちょっと待てよ、これは規制に準拠しているだろうか」というフィルターを通して確認するのでしょうか？どのような順番で物事を考えているのでしょうか？

0:01:18 セブ・レール・ベネット (Seb Leal Bennett)：間違いなく前者です。作って終わりにして、どうなるか様子を見るというものではありません。クラウド上で使用するサービスについては、それらを使って何ができるのか、何ができないのか、そこにどのようなデータを保存できるのか、そしてどのように利用できるのかという点において、極めて厳格なプロセスを確実に経たものだけを使用するようにしています。したがって、アーキテクチャの構築や開発において利用できるサービスは、すでに承認されているものだと把握できるわけです。ただし、そうしたサービスを利用する際は、適切に使用していることを確認することが依然としてお客様の責任となります。そのため、データ主権や法管轄に関する懸念がある場合は、使用しているサービスが適切なゾーン、適切なエリア、適切な地域にあり、それを証明できるようにすることが重要になります。そのため、当社は高度な規制を受けており、使うすべてのサービスが同じ規制を遵守するように徹底しています。

0:02:04 Seb Leal Bennett: また、これに日々取り組んでいる専門チームもありますが、非常に困難なプロセスです。私たちのサービスの1つで一度行ったとき、これらの人々は多くのことをやっているんだなと思いました。

0:02:13 Emily Wearmouth: 速度が低下すると思われますか?自分のセクターを他のセクターと比較した場合、イノベーションを取り入れるスピードが制限されますか?

0:02:24 Seb Leal Bennett: 少しはそうだと思いますが、大規模な組織では忘れてはならないのは、大規模なテック組織である場合、独自のポリシーやプロセスを経る必要があるため、処理が遅くなる可能性があるということです。しかし、適切に使うようにすることも確認する必要があります。なぜなら、もし間違えて市場から外れて市場に影響を与えるような事態を引き起こしたり、データが流出したりした場合、評判へのダメージは計り知れないからです。そのため、そのリスクすら冒せません。そのため、ゆっくり着実に進め、最初から正しく行う方が、規制当局が「これがいけないことだ」と見せしめにするような対象になるよりも良いのです。誰もそんな人間になりたくありません。

0:02:58 エミリー・ウェアマス： 私はあなたをクラウドとアーキテクチャとして紹介しました。ご自身の作業のうち、どの程度がクラウド上で行われていますか？完全にクラウド環境ですか、それともオンプレミスとクラウドが混在するハイブリッド環境で作業されていますか？

0:03:14 セブ・レアル・ベネット（Seb Leal Bennett）：それはアプリケーションや利用可能なテクノロジーによって大きく異なります。したがって、低レイテンシが求められるものはすべて、オンプレミスに留まり、データセンターの隣にあるコロケーション施設に置かれることになります。例えば、平均的な3層アプリケーションのようなものがあり、クラウドに移行できるミドルウェア層やバックエンド層がある場合は、それをクラウドに移行することができます。理にかなっている限りは。アプリケーションの10％または100％をそこに移行しなければならないという指標があるからといって、ただやみくもに移行を進めてはなりません。その方針が理にかなっている限り、ぜひ推し進めてください。

0:03:46 エミリー・ウェアマウス（Emily Wearmouth）：そして、そのハイブリッドアプローチはどのくらいの複雑さをもたらすのでしょうか？すべてをひとつの方法にする場合でも、別の方法にする場合でも、単一のアプローチを設計しているつもりであっても、結果的に2つの異なるアプローチや、2つの異なるシステムおよび構造を重複させて構築することになってしまいます。そこにどのような複雑さがあるのでしょうか。

0:04:04 Seb Leal Bennett:そうですね、これもアプローチによって異なります。そのため、ハイブリッドアプローチを採用することも可能です。ハイブリッドアプローチとは、非本番環境をクラウド上に構築することで、停止させたり、効率性を高めたり、柔軟性を確保したりできるという点です。その時間帯や週末でなければ、必要ありません。コストを節約するためにオフにします。必要なサービスが揃っていないため、クラウド環境で本番稼働させることはできません。そのため、これら2つのスタックを維持するか、あるいはすべてのアプリケーションや環境をオンプレミスまたはクラウドのどちらかに統一するというアプローチをとることも可能です。ですからやはり、そこで適切な決定を下すのは、アーキテクトとチームに委ねられています。私たちはガイドしたり、支援したり、同じ方向を示して情報を提供することはできますが、決して「一律にすべてに当てはまる」というものではありません。正しい意思決定ができるよう、アーキテクトのサポートに非常に大きく依存しています。

0:04:53 Emily Wearmouth：組織全体で特定の1つの方法を義務付けるのではなく、ケースバイケースで、誰もが異なる要件に対応するという分散型の意思決定アプローチを採用することには、どれだけのメリットまたはデメリットがあるのでしょうか。それによって、すべてのビジネスケースに合わせてカスタマイズされ固有のものとなった、手に負えないスタックが生じるリスクや可能性はどの程度高まるのでしょうか。

0:05:21 Seb Leal Bennett：そうですね、それを回避する方法（回避する方法という表現は違いますね、それにどのように対処するかという点ですが）は、優れたガードレール、優れた標準、優れたパターンを導入することです。最初のチームがアーキテクチャおよびガバナンスプロセスを通じて適切な会話を成立させれば、それが繰り返されるパターンとなるため、すべてのチームが同じ話を30回も繰り返す必要がなくなります。そうしないと、約30のチームがあり、おそらく同じことを行うのに60通りの異なる方法が存在することになり、それは非常に効率が悪くなります。だからこそ、アーキテクチャとガバナンスが非常に重要になるのです。私たちが処理を遅くしていると考える人もいますが、その一方で、いわゆる「秘密が漏れてしまった」場合、それを元に戻すのは少し難しいということです。

0:05:58 Emily Wearmouth：先ほど主権についてお話しされていましたが、それが最新のテーマであるため、主権について触れたいと思いました。今年が始まったとき、AIがバズワードでした。AIがなくなることはありませんが、AIの主権であれ、より広範なデジタルやデータの主権であれ、主権がバズワードになっているように感じられます。国際的な組織として、主権に対するこの関心の高まりをどのように捉えていますか。

0:06:24 セブ・レアル・ベネット：実際、私たちの組織では最初からデータが存在できる場所と存在できない場所という概念があったため、現在の状況でも問題ないと考えています。そのため、これは私たちにとって新しいことではありません。当社には、実行できることとできないことを規制する規則があり、それはこれまでもこれからも変わりません。そのため、非常に重要になります。スイスのデータであれ、リヒテンシュタインであれ、台湾であれ、許可されたゾーンの外にデータを流出させることはできません。使用しているサービスが、その地域の規制当局からも、そのクラウドサービスプロバイダーが適切なツールを提供していることを認識しているという承認を受けていることを確認する必要があります。通常、アプリケーションで適切に実行されていることを確認してください。そして、データが境界の外に漏れ出している場合は、それを発見して確認し、対処するためのツールを備えておく必要があり、おそらく規制当局に「申し訳ありませんが、失敗してしまいました」と自らレポートする必要が生じます。

0:07:18 セブ・レアル・ベネット：申し訳ありません。この問題に取り組んでみましょう。Never hide

0:07:21 Emily Wearmouth:It.先ほど主権についてお話しされましたが、現在非常にホットなトピックであるように感じられるため、この点について改めて触れたいと思いました。マクロ政治のレベルにおいて、特定の国家が自国のデジタルサービスの貿易輸出を管理することにした場合どうなるかを示すような事例が、最近いくつか見られます。そしてそれは、それを支援する主権に関する回復力の議論になりつつあります。つまり、国内の自国市場内で完結していれば、他国の規制変更に振り回されることはなくなるということです。しかしもちろん、インフラストラクチャのグローバルな性質こそが、別の方法での回復力を生み出す要因となっています。いわゆるブラックスワンイベントなどの理由で特定の国で障害が発生した場合に備えて、近隣または国境を越えたバックアップを確保しておきたいのです。主権について、またどのようにアプローチするかについてどのように考えていますか？

0:08:15 Emily Wearmouth:これは回復力でしょうか、それともそうではないでしょうか。

0:08:18 Seb Leal Bennett:興味深いですね。法律により、データが特定の管轄区域外に出ることは禁止されます。管理団体の外部にそれを保存することは許可されていません。つまり、中国では省レベルでの規制が非常に厳しいということです。スイス政府は非常に厳格であり、一部の分野では英国も同様であることは明らかです。そのため、法律の枠内でレジリエンスを維持する必要があります。つまり、イギリス、フランス、スウェーデン、ノルウェーなどに、複数のデータセンターやリージョン、クラウドサービスプロバイダが存在しています。それらはすべてそこに揃っています。したがって、データがどこにあり、どのゾーンにあるかを把握し、他の場所に保存することはできないため、それらのサービスを利用して法令を遵守して行動する必要があります。したがって、複数のクラウドサービスプロバイダを利用しているだけでなく、オンプレミスのデータセンターもおそらく保有していることになります。そのため、リージョンやゾーンの障害に耐えることがどうしても重要である場合は、内部でデータをバックアップすることが可能です。

0:09:18 セブ・レアル・ベネット（Seb Leal Bennett）：あるいは、マルチクラウドのアプローチを採用すると、費用がかかります。イングレスおよびエグレスのデータコストが発生するため承知していますが、そのサービスの重要度や、データセンターの場所に関する地政学的な災害や自然災害に耐えられるようにどのようにサービスを設計する必要があるかによって大きく異なります。だからこそ、可能であれば、クラウドサービスプロバイダーのゾーンの場所、または少なくともそれらの間の距離を理解しておくことも非常に重要なのです。そのため、ゾーン1で洪水が発生したことがわかっている場合、データがゾーン2やゾーン3にも複製されていれば、問題ないことがわかります。しかし、すべてが非常に近い場所にあるか、3つのうち2つのクラウドサービスプロバイダーを利用している場合は、バックアップがもう一方にあることを確認するために、どちらの2つが近いのかを知る必要があります。そしてそれは本当に重要です。

0:10:03 エミリー・ウェアマウス（Emily Wearmouth）：そして、ベンダーからそうした情報をどのように入手しているのですか？そして、リスナーの小規模な組織の担当者よりも、大手金融組織にいるあなたの方がより多くの情報を得られると思いますか？

0:10:14 セブ・レアル・ベネット（Seb Leal Bennett）：クラウドサービスプロバイダーとの関係性によると思います。情報を入手できることもあります。実際の場所は、いいえ、それを取得することは間違いなく不可能ですが、彼らにその間の距離を尋ねることはできます。それは不合理な質問ではないと思います。私たちが利用しているサービスプロバイダーでは、サブスクリプションを作成する際に希望するゾーンを指定できますが、どのサブスクリプションでも、ゾーン1は内部的には異なる実際の物理的ゾーンになります。そのため、例えば全員がゾーン1やゾーン3に集中するようなことにはなっていません。これにより、全員が同じゾーンに殺到するのを防ぐことができますが、APIを提供しており、実際の内部にある物理ゾーンがどれであるかを確認できます。ゾーン1、2、3のどれですか？そのため、お客様のゾーン3が、実際には物理ゾーン2にマッピングされている可能性があります。ですから、その情報を使って、それが物理的にどこにあるかを割り出すことができます。

0:11:02 セブ・レアル・ベネット：そして、その他の情報を活用することで、データの保存場所について適切な選択を下し始めることができます。

0:11:07 エミリー・ウェアマウス：ラベリングのせいで、ほとんど必要以上に分かりにくくなっているように聞こえます。そこに少し明確さを導入できる気がします。

0:11:15 セブ・レアル・ベネット：その通りですが、それには非常に明確な理由があって行われているのです。例えば、ゾーン1やゾーン3に集中しすぎてゾーン2がガラガラになってしまうのを防ぐためです。その背景にある理由を理解できるようにするためです。

0:11:26 エミリー・ウェアマス（Emily Wearmouth）：ええ。セキュリティ上の理由から特定の情報を隠蔽しなければならないことがわかっている場合、距離について尋ねることは、リスナーの皆様にとって非常に有益な質問になると思います。

0:11:39 セブ・レアル・ベネット（Seb Leal Bennett）：正確に1キロメートルか2キロメートルかを知る必要はありませんよね？10社以上ですか？30社以上ですか？正確かつ情報に基づいた意思決定を行えるよう、相手があなたに提供する必要のある情報を巧みに難読化することができます。

0:11:52 エミリー・ウェアマス（Emily Wearmouth）：組織として許容範囲とみなす基準をご自身で持っていらっしゃいますか、あるいは、何が受け入れられるかについてのガイドラインを提唱されていますか？それとももう少し流動的で、相手が提供しているものを見てから特定のユースケースに基づいてリスクを判断していらっしゃいますか？

0:12:09 セブ・レアル・ベネット（Seb Leal Bennett）：当社には独自のポリシーと手順があるため、何が許容されるか、またデータセンター間の距離がどのくらいであるかを把握しています。すべてオンプレミスであった頃にもデータセンター間に距離がありましたが、クラウドサービスプロバイダーに関しては、それと同等以上の基準を遵守しようと努めているからです。

0:12:25 Emily Wearmouth:大きな国土を持つ市場では、より簡単なのかもしれません。つまり、私たちは2人とも英国にいます。英国は世界でそれほど大きな国ではありません。国土の広さはかなり制限されています。

0:12:37 セブ・レアル・ベネット：その通りです。たとえば、国内の東西の端であったり、ロンドンのどちらかの側に位置することになります。両方のデータセンターが機能停止する原因となる事象について考え始めるからです。正直なところ、もしそれが起きた場合、特定のサービスの立ち上げ方法を検討することよりも、対処すべきより大きな問題が生じることになります。

0:12:55 エミリー・ウェアマス：はい、その通りです。ゼロトラストについてお話しできますか？

0:12:59 セブ・レアル・ベネット：はい、お話しできます。

0:13:01 エミリー・ウェアマス：ハイブリッド環境の運用について少しお伺いしましたが、アクセスやアクセスインフラストラクチャを検討する際、同様にハイブリッドなアプローチを作成する必要があるのかどうか、またゼロトラストポリシーを導入しているか、またはそれを支持しているか、そしてハイブリッド環境全体でそれをどのように管理しているかについて教えていただけますでしょうか。

0:13:21 セブ・レアル・ベネット：基盤となる認証および認可システムは同じです。銀行の標準があり、銀行のシステムがあり、それらはクラウドセールスプロバイダーのものとネイティブに統合されます。したがって、3つの異なる場所で権利が制御されるという状況にはなりません。1つを持ち、真実のバージョンが1つ、真実のソースが1つあり、最小権限の原則に従っていることを確認する必要があります。そのため、簡単だからといって全員にアクセス権を与えるわけではありません。役割を遂行するために必要な情報とアクセス権を与え、それだけです。そうでなければ、7つの異なる問題が発生する可能性があり、そのような状況には直面したくないはずです。そのため、権利やシステムを分散させないようにしてください。クラウド用やオンプレミス用というように分けるのではなく、1つだけ持ち、それが真実のバージョンとなります。

0:14:07 エミリー・ウェアマス：AIについてお伺いしてもよろしいでしょうか？AIと言うと、嫌がる人もいます。避けて通れないトピックのように思えます。なぜなら、あなたがどれほど主導権を持っているかを知ることに興味があるからです。非常に大人数のチームで、細分化された責任を分担しながら仕事を進めていらっしゃるのだと推測します。現在検討していることや、物事を計画する方法において、AIはどれほど影響を与え、あるいは変化させていますか。

0:14:31 セブ・レアル・ベネット：AIはどこにでもあります。AIがどのように役立つか、まだ気づいていないのです。全く話が変わりますが、先日志人とAIについて話していて、その方の娘さんがダンスと歌に夢中だそうです。そこで私は、「AIがそこにどう役立つというのですか？」と尋ねました。歌に関して言えば、AIはそれを音程やトーンとして捉えるからだそうです。娘さんは、AIが自分のキャリアに影響を与えることに対して最初こそ完全に懐疑的だったのですが、突然、歌のピッチを完璧にするためにAIを使い始めたのです。フレームが固定されてしまうためまだ動画はお見せできませんが、AIがどのように役立つかを実際に知れば、皆さんもちろんだれでも試してみるべきだと気づくはずです。ですから、仕事でもプライベートでも実際に触れてみなければ、日常生活の中でAIを活用できる場面には気づけないでしょう。良い例ですが、最近、頻繁にオフラインになるCCTVシステムのログファイルが大量に手に入りました。

0:15:21 セブ・レアル・ベネット：それをそのままClaudeにアップロードして、「どうなっているんだ？」と聞いたんです。3つの障害を見つけ出すことができ、VLANの設定を間違えていたことを正確に特定してくれました。これは本当に素晴らしいことです。私のほうでは絶対にできなかったことです。サポートチケットを起こしていたところでしょう。話を仕事に戻しましょう。

0:15:35 セブ・レアル・ベネット：試して、いじって、遊んでみてください。何が重要で、何を突き止めようとしているのでしょうか。なぜなら、同じ作業を1、2回以上繰り返している場合、適切なプロンプトさえあれば、確実に効率化の助けになるからです。また、人々が見落としがちだと思うのは、自分でプロンプトを書こうとしたり、AIを使ってプロンプトを書いたりすることです。これも、前進するための大きな助けとなります。したがって、アーキテクチャの分野では、「実際、こうした原則やパターン、ガードレール、エンタープライズ要件がすべて揃っているなら、それらをコード化して、コードツリーやソリューションアーキテクチャドキュメント、設計ドキュメントに対していくつかのエージェントを実行できるようにすることはできないだろうか」と考えて始めることができます。そして、ここで良い点は、アーキテクトが30ページに及ぶドキュメントの中から設計上の弱点を見つけ出そうとするのではなく、AIエージェントが「実際、ここは、ここ、そしてここを中心に確認することをお勧めします。優れた動作に対して単に形式的な承認を与えるためにそこにいるわけではないからです」と言えることです。

0:16:26 セブ・レアル・ベネット (Seb Leal Bennett): 例外事項を理解するために参加しているのです。BCMが正しく機能しているという事実に基づき、なぜ戦略に反する行動をとるのかについて40分かけて話し合うよりも、10分で話し合うほうが得策です。

0:16:37 エミリー・ウェアマス (Emily Wearmouth):そうですね。そして、チーム内でのAIの利用についてはどうですか？チームのリソースを長期的にどのように配分するか、そうしたモデルがどうなるか、新しい人材をチームにどのように迎えるか、そしてそれによって新しい人材に対する見方がどのように変わる可能性があるかについて、ご自身の見解に変化が見られますか？

0:16:55 セブ・レアル・ベネット (Seb Leal Bennett):AIがチームに取って代わるとは考えていません。AIはチームを補佐して効率性と有効性を高めるために存在しており、質問した際に回答が得られた後、「それと同時に…」といった形で反対の視点も提示してくれます。そして時には、「それと同時に…」という要素によって、「おや、ちょっと待てよ」と考えさせられることがあります。これについては異なるアプローチをとることもできます。「そのため、単に電子メールを作成したり電子メールを変更したりといったタスクを実行するために使うこともできますし、チームの一員にしたり、一緒に作業しながらフィードバックを返したり、あるいはソリューションを提案してより自律的に動くようにしたりすることもできます。」このように、AIを統合できるレベルは多岐にわたります。自分が快適に行えること、そしてその次に行いたいことです。

0:17:33 エミリー・ウェアマス (Emily Wearmouth)：時には、自分が快適に感じられないことこそが重要であるとも言えるでしょう。先週、少しトゲトゲしい気分だったので、Claudeを使って、そんなにお世辞を言わないように頼んでみました。少し前にもうコツを掴んでいて、そこまで悪くはなかったのですが、どうしても気になって仕方がなかったのです。そして、徹底的に無愛想にするようにお願いしました。そして先週一週間は、あまりにも攻撃的に無愛想だったので、もう一度設定を変えて、「いや、もう少し優しくしてくれていいんだよ」と言わなければなりませんでした。誠にありがとうございました。「しかし、その週の間、以前なら提案しなかったようなことを提案してきたのです。」中には完全に間違っているものもありました。彼らは単に議論のためだけに議論していたのです。しかし、自分が快適に感じることや、どのように話しかけられる準備ができているかという障壁を取り除くことで、例えば、もし自分がそれに文句を言うことを許可していなければ今週は起きなかっただろうということがいくつかありました。

0:18:18 Seb Leal Bennett:まったくその通りです。ですから、すべてはプロンプトと、どのように連携させたいかにかかっています。「常に私に同意しないでください」と言うことができます。私は常に正しいとは限りません。この特定のボットやエージェントとしてのあなたの仕事は、私に反対することではなく、私に逆らうことですが、私たちがまだ探求していない領域を見つけることでもあります。「そして、それらの質問をし、それらのプロンプトを尋ねることを忘れないようにするということであり、時には少し時間がかかることがあります。そのため、同じような質問をする人がたくさんいる場合は、プロンプトストアを用意し、コピーして貼り付け、持ってくるといった方法をとります。そのため、この分野でできることはまだまだたくさんありますが、文字通りまだ始まったばかりです。

0:18:50 Emily Wearmouth:チーム全体でその知識を構築するために、非公式であっても、あるいは単にチームと一緒に何か組織的なことを行っていますか?私が見つけているのは、非常に快適に感じて先に進んでいる人がいる一方で、あまり快適ではない人や試行錯誤する時間があまりない人を支援するための仕組みを整える価値が十分にあるということです。チームが一体となって動くようにするために、週末に4時間を費やしてスキルアップすることができないような事情があるのかもしれません。構築を進めているものは何かありますか？

0:19:16 セブ・レアル・ベネット（Seb Leal Bennett）：共有することが重要だと思います。そのため私のチームでは、何も求めずに2週間ほどミーティングを行い、「AIに関して誰が何をしているのか？何が興味深かったか、どのようなことをしたのか教えてほしい」と話し始めました。そして、それは職場環境だけに限りません。自宅などでも、どのようなところで成功を収めましたか？どこで失敗しましたか？そして、どのようなことを学びましたか？ですから、単にそれについて話し合い、何が機能していないのかを理解することがすべてなのです。そして当然のことながら、より多くの自由時間を持っていたり、それに投資してさらに一歩進む時間を取ったりする人々も存在します。そしてまた、彼らは戻ってきて、「このようなことを行ったので、皆さんもそこから学ぶことができます」と言うことができるのです。ですから、チームとして一丸となって取り組むことが本当に重要であり、1人や2人だけで先走るのではなく、それが前に進むための方法であると考えています。

0:19:59 Emily Wearmouth:はい。セキュリティについて、また「Security Visionaries」ポッドキャストについてお話ししたいと思いました。セキュリティに特化した質問をしないわけにはいきません。セキュリティチームそのものではなく、セキュリティ専門家と協力して仕事を進められていることは承知していますが、アーキテクチャリードとして、セキュリティチームは最初から同席しているのでしょうか、それとも後から加わるのでしょうか。プロセスのどの段階でセキュリティを関与させる傾向があるか、また、後から関与させる場合は「By Design（設計段階からの）セキュリティ」と言えるのかどうかについて教えてください。What

0:20:35 Seb Leal Bennett:後から関与させるとはどういう意味でしょうか？自分でゼロからアプリケーションを構築して「よし、ここで認証と認可を追加する必要があるな」と考えて進めるのとは異なり、組織として厳格な標準や再利用可能なコードパターンが備わっているため、デフォルトでセキュリティが組み込まれるからです。OSSやその他の商用製品を導入する際には、セキュリティが非常に重要であり、最初から考慮されている必要があると思います。「この権限管理システムを銀行のシステムにどのように統合すべきか？」という点を検討する必要があるでしょう。ユーザーに対する過剰なプロビジョニングを防ぐため、最小限の特権のみが付与されている状態をどのように確実にするのでしょうか。統合パターンを十分に理解しておらず、誤って何かを省略してしまったために、知人に管理者権限を付与できるような権限が与えられてしまったケースを見てきました。明らかに、それは起こりません。意図的に行っているわけではありません。

0:21:35 Seb Leal Bennett：単にそれを外し忘れていたような形です。そのため、セキュリティは本当に重要であると考えています。それに対する統一されたアプローチはないと思いますが、CISOチームと連携し、組織にアプリケーションを導入する際の方法として、最初からアプリケーションに組み込まれているようにすることが非常に重要です。そうしないと、最終的に問題が発生することになります。しかし、「クラウドファースト」の台頭期には、パスワードなどが記載されたまま、誤ってBlobストアを一般公開したままにしてしまったケースが見られました。そのため、最初からしっかりと固めておくことが非常に重要であり、そうしないと問題が発生することになります。そして、その点はしっかりと対応済みです。彼らは素晴らしいです。あらゆるものに適用されます。だからこそ、サービスプロバイダーからサービスを利用して利用可能にする場合、それらがその一部となり、しっかりとロックダウンでき、データが流出しないように確実に保護できるといったすべてのことが実現できるようになります。

0:22:23 セブ・レアル・ベネット：そのため、エンジニアとして使用する際にも、正しい方法で使用しているという確信を持てます。

0:22:29 エミリー・ウェアマウス：興味深いことに、誰かにその質問をすると、あなたと同じように、私の尋ね方に対して少し懐疑的な反応を示すことがあります。このように尋ねる理由は、セキュリティ専門家にその質問をすると、「自分の組織では本当にイライラさせられます」と言われることがあるからです。セキュリティが導入される前に、すでに物事が進んでしまっているのです。そのため実際に起こることですが、それが皆様の経験ではなく、セキュリティと一体となって進んでいると聞けて大変嬉しく思います。

0:22:55 セブ・レアル・ベネット：はい、そうしなければなりません。そこで間違いを犯す余地はありません。

0:23:22 セブ・レアル・ベネット：はい、その通りです。そのため、私たちは常にそこに注目しており、新しいテクノロジーであるクラウドが登場するやいなや、誰もが飛び込んでいきます。いわばお菓子屋さんの子供のようなものです。しかし、正しいやり方で行われているかを確認するための対策が講じられていなければ、過剰な出費につながってしまいます。そして、組織がクラウドへ移行する際、オンプレミス環境のスタックとクラウド環境のスタックの両方を運用していることが分かります。そのため、コストがすぐに倍増してしまいます。したがって、オンプレミス環境のスタックをできるだけ早く排除する必要があります。しかし、クラウド環境であっても、チームが作業内容を把握していなければ、コストが高額になる可能性があります。例えば、オンプレミスでストレージを導入する場合、「どれくらいの容量が必要ですか？」と問うことができます。どのような種類が必要ですか？どこに必要ですか？また、バックアップは必要ですか？よく尋ねられる質問が4つか5つほどあります。

0:24:06 Seb Leal Bennett:クラウドにおけるストレージについて検討し始めると、必要な連続読み取り/書き込みIOPsの数など、15から20ほどの質問があります。エンジニアは元々そうした質問に答えるようには設計されていないため、間違えてしまいます。そのため、過剰なプロビジョニングを行っています。そして、過剰にプロビジョニングを行っているため、そのコストを支払うことになります。そのため、コストを見直すための何らかのガバナンスやフォーラム、あるいは仕組みを持つ必要があります。「過剰にプロビジョニングを行っていないか」ということです。コストを削減できる場所を特定できますか？例えば、実際にはコールドストレージで十分であるにもかかわらず、すべてのストレージをホットストレージに配置している場合があります。価格差が大きいです。非本番環境の資産が24時間365日稼働しているという事実があるかもしれません。夕方や週末に稼働させる必要はおそらくないため、停止し、必要なときに有効にしてください。コスト削減の方法については、非常に多くの異なるアプローチがあります。

0:25:54 Seb Leal Bennett:したがって、クラウドはコスト対策ではなく効率化対策であると言われているため、アプリケーションを正しく設計し、最初からクラウドで適切に行動していれば、コスト面で有利になる可能性があります。そして、その虫眼鏡を取り出し、そうした節約を見つけて共有するのです。1人の人間や1つのチームだけで行うものではありません。例えば、実際の年間コストの10％を削減できたとしたら、それを実現する仕組みが必要です。他にはどのような人がそれからメリットを得られるでしょうか？そして、それを自動化する方法を見つけます。ですから、これらの5つのステップを実行するように言うのではなく、「そこに10％の節約効果があると思われます」とデータを示して人々に提示し、それに対して追跡を行うのです。OKRを切望し、トップからそれを浸透させれば驚くことでしょう。平均して、すべてのクラウド支出の30％が無駄になっていると思われるからです。おや。当社はこの分野に多額の投資を行っています。

0:25:42 セブ・レアル・ベネット（Seb Leal Bennett）：毎年、銀行全体で設定するOKRがあり、それを追跡し、追求し、確認し、共有しています。それが最善の方法です。

0:25:52 エミリー・ウェアマウス（Emily Wearmouth）：そして、その30％の大部分は過剰プロビジョニングによるものだと思いますか、それともまったく使用されていないサービスによるものだと思いますか？

0:26:03 セブ・レアル・ベネット（Seb Leal Bennett）：両方が混ざり合っています。主に、過剰プロビジョニングです。実際、先日子どもの統計を少し見ていました。2023年からどれだけ節約できたかを運用し、カテゴリー分けしてきたからです。その大部分、つまり約3分の1、あるいはそれ以上が過剰プロビジョニングによるものでした。今、私たちは物事をオフにし始めています。それも非常に大きな要因になっていることがわかります。しかし、アプリケーションをクラウドネイティブにすることも重要です。つまり、すべてのクラウドプロバイダーが、適切に設計し、クラウドネイティブにし、弾力性を持たせ、必要に応じてゼロからヒーローへとスケールするように作れと言っているのです。つまり、週末であっても自動的にシャットダウンするということです。それだけのことです。不要なところには支出しないようにしましょう。

0:26:41 エミリー・ウェアマウス：過剰プロビジョニングについて話すとき、楽観主義に傾きがちなビジネスストーリーがあるのに、いつも疑問に思うのです。ビジネス側は成長計画や規模拡大の意図を投影したいと考えていますが、ビジネスの現場では、そのうちどの程度が単なる虚勢やアピールであるかを見極める必要があります。現実的に考えて、積極的な成長に合わせて構築およびプロビジョニングを行う必要があるでしょうか、それとも、万が一の事態に対応できるスケーラビリティを備えた中間地点に合わせて構築できるでしょうか？組織が市場に向けて発信しているメッセージにどの程度耳を傾けるべきでしょうか。また、過剰なプロビジョニングを避けるために、それらをどの程度調整する必要があるとお考えですか？

0:27:22 セブ・レアル・ベネット（Seb Leal Bennett）：当社のビジネス部門は自社の市場を完全に把握しています。彼らは自分たちがどこを成長させたいのかを把握しています。当社には過去のデータがあるため、高水準のしきい値がどこにあるかを把握しており、全体的にどのように上昇しているかを確認できます。市場に影響を与えるイベントによって新たな高水準のしきい値が作成されるかどうかがわかります。重要なポイントは、どの組織においてもすべてのチームがこの点に優れているわけではないということですが、それはSLAや品質属性です。そのアプリケーションをどのように動作させるように設計する必要がありますか？なぜなら、それは設計やコストの面でも非常に重要だからです。例えば、ウェブサイトがある場合、そのページは0.5秒以内にレンダリングされる必要がありますか、それとも実際には30秒でも問題ありませんか？その質問に対する答えによってアーキテクチャが変化するため、そのアーキテクチャのコストがどうなるか、またスケールアップとスケールダウンがどのくらい容易であるかという問題が生じます。

0:28:09 Seb Leal Bennett:もしそうした質問をせず、ビジネス側との会話の中で好奇心を持って臨まなければ、アプリケーションの規模を過大評価するか、あるいは過小評価することになります。したがって、的確に核心を突くためにその会話を行い、それを基にして進めていく必要があります。ビジネスに必要なSLAと品質属性を確実に取得してください。彼らはそれを使って何をしたいのかを分かっていますが、あなたの方からも意見を主張することができます。しかし、そこから重要な要素となるデータを使ってください。主観的な会話はやめましょう。「実際のデータを見ると、我々にはこれが証明できます。現在の状況において、これに対応できるよう拡張できると考えています。さらに必要であれば、クラウドに移行し、可能であれば弾力的にスケールアップすべきです。

0:28:50 Emily Wearmouth:これが0.5秒でロードされる必要があるのか、それとも30秒かかってもよいのかという点についておっしゃいましたね。私の頭にはすぐにエージェント型AIが思い浮かび、それが物事をどのように変えていく可能性があるかと考えました。人間が操作できるようにアーキテクチャを構築する場合、私たちの忍耐力、あるいは私の忍耐力かもしれませんが一つの忍耐力は非常に限られており、物事が非常に迅速に実行されることを望んでいるためです。しかし、それがそのアーキテクチャのプロセスとやり取りする人間のプロセスではなくなり、エージェントである場合、うまく機能しない領域に対しては、より大きな許容範囲を受け入れることができるかもしれません。最終成果物が超高速である必要がなく、時間制限がない限り、エージェントはより低速なルートに対してもより寛容になり、コストのかからないサービスに対してより大きな許容範囲を持たせることができます。

0:29:34 Seb Leal Bennett：それは可能であり、すべてはその特定の機能に求められるユーザーエクスペリエンスとは何かという点に帰着します。エージェント型であろうとななかろうと、それがアーキテクチャを決定づけることになります。でもそうですね、それは興味深いポイントです。

0:29:45 Emily Wearmouth:そうですね。それは私からのセブへの無料のプレゼントです。それは受け取れます。書き留めて

0:29:51 Seb Leal Bennett:おきます。

0:29:51 Emily Wearmouth:日々の業務に価値を。素晴らしい。時間への配慮はしておりますが、多くの時間を頂戴してしまいましたし、お客様にはこの後別の会議のご予定があることも承知しております。それでは、セブ、本当にありがとうございました。この会話を非常に楽しむことができました。リスナーの皆様にも同様に楽しんでいただけたことと思います。

0:30:05 Seb Leal Bennett:素晴らしい。ご招待いただきありがとうございます。非常に楽しかったです。今後のエピソードにもぜひ出演したいと思います。

0:30:09 Emily Wearmouth:素晴らしい。セキュリティビジョナリーポッドキャストをお聴きいただきありがとうございます。ホストのエミリー・ウェアマスがお届けしました。このエピソードをお楽しみいただけましたら、ぜひシェアしていただき、お気に入りのポッドキャストプラットフォームやYouTubeでフォローしてください。そうすれば、今後のエピソードを見逃すことはありません。それでは、また次回お会いしましょう。