re:Invent 2024: AWSのセキュリティカルチャー構築 - Guardiansプログラムの成果
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Building a resilient and effective culture of security (SEC217)
この動画では、AWSにおけるSecurityカルチャーの構築方法について、AWS IdentityのBridget JohnsonとAWS SecurityのBill Shinが解説しています。Securityを組織文化として根付かせるための3つの柱として、価値観と規範、共有される行動、知識の普及を挙げ、具体的な取り組みを紹介しています。特に注目すべきは、5000人以上のエンジニアが参加するGuardiansプログラムで、これによりAECレビューでのブロック指摘事項が22.5%減少し、年間21万作業日の節約を実現しました。また、Weekly Security MeetingやThreat Modelingの実践など、具体的な施策を通じて、Securityを組織の最優先事項として定着させている様子が詳しく語られています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
AWSセキュリティリーダーによる自己紹介と本日のテーマ
ご来場ありがとうございます。皆様にお越しいただき、大変嬉しく思います。木曜日にもかかわらず、大勢の方にお集まりいただき、会場も活気に満ちています。週末も近づいてきましたが、皆様良い一週間をお過ごしでしょうか。本日、会場を歩き回りながら参加者の方々に参加理由をお聞きしたところ、驚くべきことに全員が同じテーマを挙げていました - それはSecurityです。この会場にいらっしゃる皆様のほとんどがSecurityに関心をお持ちだと思いますが、組織の中でSecurityを気にかけているのが自分一人だけという状況は避けたいはずです。今日は、Cultureについて、そしてどのようにCultureを活用すれば、皆様や組織にとって重要なSecurityの成果を確実に高められるかについてお話しします。
本日は、私が一緒に仕事をさせていただいた中でも特に素晴らしいお二人をお招きしています。お二人は全く異なる視点を持っています：サービスチームの視点、エンジニアリングの視点、そしてSecurityリーダーシップの視点です。Bridget Johnsonです - AWS Identityで10年間働いてきました。Identity、アクセス管理ポリシーなど、Identity関連のすべてが大好きです。皆様にとって重要なAWSサービス - Identity Center、Access Analyzerなどの開発・運用を担当しています。私のチームが日々Securityのレベルを上げ続けていることを、皆様も気にかけていらっしゃると思います。私のチームやエンジニアリングチームがそれを確実に実行できるよう、Securityチームと密に連携しており、本日は主にサービスチームの視点からお話しさせていただきます。
私はBill Shinです。AWS SecurityのSenior Principalとして、CIOオフィスで働いています。AWSには12年以上在籍しており、AWS初のSpecialist Solution Architectとして入社しました。Securityが私たちにとって最優先事項であるため、私の専門はSecurityでした。最初はフィールド向けの役割で、お客様もAWSもSecurityを確実に実現する必要がありました。入社から5年後、CIOのSteve Schmidtの下で働くことになり、CISOオフィスを立ち上げました。この役割では、ポリシーや規制関連の業務を多く担当し、サービスチームやProactive SecurityチームやAECチーム、Security Operationsチームと密に連携しています。また、セールス組織のテクニカルフィールドコミュニティのリーダーも務めています。
セキュリティの成果とカルチャーの重要性
お二人とも役割について控えめにおっしゃっていますが、実際には、それぞれが所属する組織のCultureにSecurityを根付かせる上で、非常に重要な役割を果たしてこられました。 では、私たちが重視する成果について話しましょう。Cultureは素晴らしいものですが、今日はSecurityの成果について話し合いたいと思います。Bridget、エンジニアリングチームのリーダーとして、あなたにとって最も重要なSecurityの成果は何でしょうか？私にとって最も重要なのは、Securityのレベルを継続的に向上させることです。そのためには、エンジニアが自分たちのシステムに精通し、システムを構築し、新機能を作り、新しいコードをデプロイする必要があります。私が重視しているのは、エンジニアが現場の目と耳となり、何か不安定な点や気になる点があれば、適切な人々に相談できる体制を整えることです。実際の問題であれ、単なる懸念であれ、問題を表面化できることが重要です。
私は、すべてのエンジニアがSecurityの問題を報告できる手段を持っていることを重視しています。 エンジニアにSecurityの当事者意識を持ってほしいということですね。それは、リーダーとして私が毎日目覚めて考えることであり、願っていることです。 そして、エンジニアが心理的安全性を感じ、Securityについて話し合い、エスカレーションできる環境を作りたいということですね。エンジニアがSecurityの問題を提起するたびに、私たちはそれを称賛します。VPにメールが送られ、VPから感謝の言葉が贈られます。私たちはこれを積極的に推進しています。なぜなら、お客様が発見する前に社内で見つけることができた方が、はるかに良いからです。
私たちは、できるだけ迅速に問題を解決できるよう、彼らがこれらの意思決定を主導できるようにすることを重視してきました。高速な意思決定は非常に重要で、それには適切な人々と適切な視点へのアクセスが不可欠です。 そしてこれらすべては、一つの大きな目的のためです - お客様にとってSecurityをビジネスの推進力にすることです。Billは過去12年間の役職で、何百、いや何千ものお客様と仕事をする機会がありました。この会場で Bill Shinにお会いしたことがある方はいらっしゃいますか？ああ、もう一人いましたね。Steve Macですね。はい、確かにSteve Macとはお会いしました。Billは多くのお客様と対話を重ねてきました。Bill、そういった対話の中でお客様にとってこれがいかに重要かについて、少し視点を共有していただけますか？
私はこのことについて多く考えてきましたが、Securityは必要なものであって、必ずしも望まれているものではありません。Security担当者は自分の仕事に大変情熱を持っていますが、それはクラウドやビジネスから価値を引き出すために必要ではあるものの、それだけでは十分ではありません。目標は、市民のための公共部門組織であれ、顧客を持つビジネスであれ、組織が望む成果を本当に得られるようにすることです。ペットフード、書籍、配送サービス、飛行機、その他何を販売しているにせよ、それが本当の目標であり、それを成功させるにはSecurityを最優先にする必要があります。そうしないと、顧客は失望することになります。
CISOやお客様と話をする際、Security teamが最終的な目標を理解することが非常に重要です。目標はSecurityのためのSecurityではなく、人々に奉仕するビジネスや組織を構築するためのSecurityなのです。私のキャリアの初期、Snortルールを書いたり、ファイアウォールを設定したり、システムを強化したりしていた頃は、その理由をあまり考えていませんでした。キャリアを積むにつれて、「このシステムは何をするものなのか？」という質問をするようになりました。データベースやアプリケーションサーバーだと言われても、それが人々にとって実際に何をするものなのかを知りたかったのです。
私たちの組織は、顧客を喜ばせるサービスを提供することが最大の目標であることを完全に理解しています。それが私たちの最優先事項であり、Securityは最重要課題ですが、コードをデプロイして顧客をサービスで喜ばせることができなければ、私たちの存在意義はありません。その成果が誰にとっても最重要なのです。ここで興味深いのは、「重荷」と「権限委譲」という対比です。私はKristenとBillを嫌うべきかもしれませんが、実際はそうではありません。私たちは一年を通じて協力し合っています。トレードオフやリスク評価を行う必要がある時は、AWS Securityのメンバーを招き入れます。彼らはパートナーであり、私たちは協力し合っています。
私はBillと長年一緒に仕事をしており、意思決定を行う際には彼の意見を求めます。継続的な協力関係を育むことが重要です。Securityとサービスチームが対立するのではなく、コードをデプロイするという共通の目標を持つ必要があります。リスクを発見した場合、それをどのように軽減し、リスクを低減するかが重要です。私は、Securityリスクを明確にし、それを軽減するために前進する中で、より良いソリューションを見つけ出せることが大好きです。
セキュリティ関連の作業のほとんどは計画的に進めることができます。予測可能なものなのです。私たちは、どのような規制環境で働いているか、どのようなコンプライアンス成果物が必要か、TLS 1.0.1を廃止する必要があること、そしてパッチ適用が必要になることを知っています。サービスチームに予期せぬ負担をかけないよう心がけています。計画的な作業において、セキュリティは時間とともに劣化していきます。緊急のセキュリティ問題でなくても、常に取り組み続ける必要があるのです。暗号化の最新化などは、何年も前から必要性を予測できることもあります。私たちにとって、最も重要なことの一つは、お客様に喜んでいただける機能をリリースする妨げにならないようにすることです。
セキュリティカルチャーの基本概念と3つの柱
このメンバーたちは、エンジニアリングとセキュリティの両面で本当に優れています。自己紹介を忘れていましたが、私はAWS Security Organizationに所属しています。後ほどご紹介するGuardiansプログラムを率いています。私たちのチームは、すべてのサービス、新機能、ネイティブサービスにおける重要な変更が、本番環境に投入される前にセキュリティエンジニアによってレビューされることを確実にすることに注力しています。私たちはカルチャーの専門家ではありません。実際、そのような訓練を受けた者は一人もいません。 そこで、本題に入る前に、カルチャーについて基本的な考え方から見ていきたいと思います。
カルチャーとは、ある集団や社会を特徴づける価値観、規範、共有された行動様式、そして知識の集合体です。価値観とは、私たちにとって重要なものです。規範とは、私たちが従う基準や期待値のことです。例えば、アメリカから来られた方は道路の右側を走り、イギリスやインドから来られた方は「間違った」側を走るといった具合です。価値観は規範に影響を与えますが、行動にも大きな影響を及ぼします。
私たちが集団として共有する行動は、あらゆる社会、文明、組織の中でパターンや慣行として現れ始めます。これらの価値観は個人の目的に影響を与えますが、知識がなければその目的を達成する機会は得られません。そのため、知識も非常に重要なのです。
今日は、これら3つの柱に沿って話を進めていきます。Security Cultureについて考えるとき、それは会社で一緒に働く人々が共有する価値観、規範、行動、そして知識であり、それがセキュリティに影響を与えるのです。人々はセキュリティにおいて重要な役割を果たします。これはフライホイールのようなものです。知識だけを与えても価値観や規範は変わりませんし、新しい行動を宣言するだけでも十分ではありません。これら3つすべてを組み合わせて取り組む必要があるのです。
エンジニアリング組織のリーダーとして、組織文化は一朝一夕には変わらないということを私は理解しています。リーダーとして、共有される行動であれ、価値観を通じて働くことであれ、一つのことを選んでゲームを変える必要があります。一つを選べば、それはフライホイールのように回り始め、成長していき、時間をかけて文化を少しずつ変えていくことができます。私たちは、自分たちにとってうまくいったことをたくさんお話しし、同時にうまくいかなかったことについても共有します。会場の皆さんには、これらの柱のそれぞれについて、2025年に自分の組織で実践できそうなことを一つだけ考えていただきたいと思います。すべてを実践しようとするのではなく、私たちの組織ではなく、あなたの組織に合うものを一つだけ見つけてください。
AWSにおけるセキュリティ価値観の確立と共有
皆さんの会社の価値観について考えるとき、CEOがその価値観の確立に大きな役割を果たしたのではないでしょうか。なぜなら、トップからの価値観の伝達が、すべての始まりだからです。私たちの組織は、過去18年間、Andy Jassyが何度も繰り返し「Securityは最優先事項である」と言い続けてきたことは、非常に幸運でした。素晴らしいのは、それが社内だけでなく、社外にも向けられていることです。皆さんは彼のインタビューやKeynoteでそれを何度も耳にしてきたはずです。そしてそれこそが素晴らしい点です。なぜなら、私たちのCustomerもそれを知っており、コードをチェックインするエンジニアに至るまで、全員がそれを理解しているからです。
Andy JassyとCIOのSteve Schmidtが確立したもう一つのユニークな点は、Securityの組織構造です。私たちのCSO SteveはAndy Jassyに直接レポートし、AWS CSOのChris BetzはAWS CEOのMatt Garmanに直接レポートする形になっています。これは意図的なものでした。Amazonが始まった当初、インターネットでクレジットカードを使って本を購入することは、かなり不安定なものでした。AmazonのDNAと文化は、常にSecurityを最優先事項としてきました。信頼がなければ - 私たちは価値観や規範について話していますが - Amazon Leadership Principlesはオンラインで公開されており、16個あるPrinciplesの一つが「Trust」で、これは私たちの会社で日々体現されています。
ご存知の通り、Matt GarmanはAWSの新しいCEOとなりました。私が特に素晴らしいと思って強調したいのは、彼がCEOになった日に全従業員に送ったメールの一部で、Keynoteでも同じことを述べていました。Andy Jassyは彼の初日に、「Customerのセキュリティを確保することがJob Zeroである」と伝えたのです。繰り返しになりますが、これはトップから始まるのです。この会場にいる皆さん、さっき話をしたCTOの方もそうですが、Securityの声となってください。必ずそれについて話し、公の場でチームやリーダーたちにそれを伝えてください。なぜなら、あなたがそれを重要視していても、それを伝えなければ、忘れ去られてしまう可能性があるからです。Securityに影響を与える仕事に日々従事している人々の心の中に、常にそれが存在するようにしたいのです。AWS CEOにCISOが直接レポートする体制により、私たちはCustomerから大きな信頼を得ています。私たちは事実上すべての国で事業を展開し、あらゆる規制やコンプライアンス環境、ほぼすべての業種で活動しており、皆さんは私たちにデータを託してくださっています。だからこそ、それは絶対的な最優先事項なのです。
CIOがCEOに直接報告するという体制は少し珍しく、すべての組織がそうしているわけではありません。このような組織構造から得られる成果を実現するための方法については、もう少し詳しくお話ししていきます。皆さんの中には、CEOにセキュリティについて話してもらい、セキュリティの価値を理解してもらうにはどうすればよいのか、と考えている方もいらっしゃるでしょう。しかし、それは彼らから始まるわけではありません。この会場にいる皆さん一人一人が、セキュリティのロールモデルになることができるのです。
ここで、そのためのヒントをいくつかご紹介します。これらは、リーダーシップにセキュリティについてより多く語ってもらうための影響力を持つかもしれません。まず一つ目は、セキュリティを推進する自社の価値観を特定することです。Billは私たちのLeadership Principlesについて話しましたが、その中の一つに「Ownership」があります。これは、コードを書くエンジニアである私たちのBuilderたちが、自身のセキュリティに対してオーナーシップを持てるようにする上で非常に重要な役割を果たしています。このように、セキュリティを推進する価値観を特定し、それを既存の価値観に結び付けることが大切です。新しい価値観を作るのではなく、既存の価値観に関連付けるのです。
共通の語彙を提供することも重要です。セキュリティについて話す際は、一貫性を持つことが大切です。「Ship Securely」は、先ほどBillが言及した言葉の一つですが、これは私が言うように指示したわけではありません。ミッションステートメントを考えていた何年も前から、私たちがよく使っている言葉なのです。その当時、Eric Brandweinは会話の中で、「AWS Securityは私たちの組織の名前だが、会社の名前はAmazon Web Servicesであり、私たちはお客様にWeb Servicesを提供するために存在している」と言いました。しかし、セキュリティが組み込まれていないWeb ServicesやAPIはお客様を喜ばせることができず、そもそもローンチさえできないサービスではお客様を喜ばせる機会すら得られません。「Ship Securely」という言葉は、そのようにして生まれ、私たちが常に口にする言葉となったのです。
曖昧さを避けることも大切です。先ほど成果の一つとして話した心理的安全性に話を戻すと、人々は伝えられる内容が明確で具体的であるほど、より安全だと感じます。そのため、このようなメッセージを考える際は曖昧さを避け、参加するすべての会議で標準化することが重要です。私たちには「Security Messaging Bar Raisers」というプロセスがあります。Hiring Bar Raiser、Crypto Bar Raiserがあるように、Security Messaging Bar Raisersもあります。これは主にPrincipal Solution ArchitectやPrincipalレベルの人々のグループで、私たちが発信するすべてのコンテンツを確認し、セキュリティに関する言語が臨床的で正確であることを確認します。
私たちは「リスク」「脆弱性」「侵害」「ハック」「攻撃」といった言葉を安易に使いません。これらの言葉は特定の状況では正確かもしれませんが、FUD（恐怖、不確実性、疑念）で売り込むことはしません。お客様に対しても社内でもFUDを生み出すことはありません。セキュリティは非常にデリケートなトピックであるため、特に公に発信されるコンテンツについては、セキュリティについて話す際の言葉が臨床的で正確であることを確認するメカニズムを持つことが非常に重要なのです。
エスカレーションカルチャーの醸成と実践
AWS Securityの週次セキュリティメトリクス会議には数百人が参加し、コンプライアンスやAppSecに関連する業務を行うAWS Securityの全マイクロサービスチームが出席することになっています。各チームは毎週メトリクスを管理し、それらを発表するよう求められることがあります。通常、発表はチームの若手メンバー、レベル1や2程度の、システムを運用している人や実務を担当している人が行います。しかし、彼らはDistinguished EngineerやPrincipal Engineerたちという心強いグループに囲まれています。この会議は追及の場ではありません。
これらの会議は、レイテンシーの低下、パケットロス、古すぎるチケット、パッチの状況、オペレーターアクセスなど、ツールやプロセスが関係するすべての事項について、誰もが質問できる学びの場であり、メトリクスを確認する場です。会議ではまず、ポジティブな雰囲気で始められるようQuick Winsから始めます。各チームは過去1週間に発生した問題についてのCorrection of Error（エラー修正）文書の読み合わせを共有し、全員がそのエラー修正プロセスから学びます。その後、その週にできる限り多くのチームのメトリクスを確認していきますが、すべてのチームが学びの機会として自分たちのメトリクスを発表できるよう準備しておくことが求められます。新人や若手社員が学び、セキュリティの基準を継続的に向上させる方法を学ぶ場となっているのです。
用語の部分に戻りたいと思います。私たちは顧客に対して外部的に共有することについて多く話してきましたが、エンジニアリングチームとして内部的にも懸命に取り組んできました。エンジニアは何か変だと感じたり、少し違和感があったり、リスクを発見したと思った場合、セキュリティチケットを切ることができます。私の組織のすべてのリーダーは必ず2つの質問をします：顧客へのリスクは何か、そして顧客への影響は何か、です。エンジニアはこれらのチケットを切り、問題を提起することに大きな安心感を持っています。なぜなら、この2つの質問は事実に基づき、正しい答えを導き出すことに焦点を当てているからです。これらの質問から、対策とコミュニケーションについても話し合うことができます。
これらが価値観です。次は規範について少し話しましょう。Jeff Bezosの話を持ち出すのは少し気が引けましたが、実際のところ、彼はAmazonの文化の確立に大きな役割を果たしました。2016年の株主向けレターからの私の好きな引用は「Day 2は停滞であり、その後は無関係になり、その後は耐え難い苦痛を伴う衰退があり、最後は死です。だからこそ、私たちは常にDay 1なのです」というものです。耐え難く苦痛なものについて考えるとき、私が思い浮かべるのは、単なるプロセスのためのプロセスや官僚主義、私のチームが何かを成し遂げるために常に乗り越えなければならない形式的な手続きです。これは実際のところ、死に等しいものです。エンジニアはそれを嫌います。彼らは物事を成し遂げることが好きなのです。エンジニアは朝起きて物事を成し遂げ、適切なタイミングで適切な方法で適切なことができることを愛しています。
私たちはDay 1の文化を大切にしていますが、それは同時に、代理指標への抵抗、プロセスのためのプロセスの回避、顧客への焦点といった規範を確立します。セキュリティに関連する規範について話しましょう。セキュリティの所有権に関する規範を持つ必要があります。エンジニアが自分たちの責任を理解するための明確性が必要です。これが私たちが確立した規範です：Amazon Web Servicesの各サービスおよびプロダクトチームは、提供するサービスまたは機能のセキュリティに対して完全な責任を負います。これがあなたの組織の規範やアプローチである必要はありませんが、何らかの明確な規範を確立する必要があります。
私は多くの顧客企業のセキュリティ組織を見てきましたが、セキュリティに関する集中管理と分散管理の間には常に適切なバランスがあります。AWS Securityはロギングや認証、開発者が使用する静的解析ツールなどの共有サービスを運用しています。私たちは社内サービスを運用していますが、サービスチームこそが専門家なのです。AWS Securityはサービスチームの専門家ではありません。私たちはそれらを構築したわけではなく、脅威やリスクを特定することはできますが、修正はできません。高い回復力と効果を持つ組織では、権限よりも専門知識を重視します。セキュリティ組織が排他的にセキュリティを所有している場合でも - セキュリティの観点では最終的な責任は私たちにありますが - サービスを修正することはできないため、彼らが所有する必要があります。
これは主に実務的な問題です。サービスチームのリーダーたちは自らセキュリティに対する責任を持ち、私たちは支援、アドバイス、相談を行い、必要な場合は最後の砦となります。しかし、彼らがセキュリティを所有していなければ、私たちは効果的に機能できません。サービスチームが立ち上がり、初めてサービスをローンチする時、必ずしも大きなチームである必要はありません - セキュリティエンジニアがいない場合もあります。しかし時間とともにシステムはより複雑で大きくなり、セキュリティは時間とともに劣化していきます。そのため、彼らが引き続き迅速に進み、良好な機能の流れを維持したいのであれば、自分たちの運命を自分たちでコントロールする必要があります。もし彼らがAppSecに戻ってきたり、セキュリティレビューを受けて問題が見つかったりすれば、コードを同じ速さでリリースすることはできなくなります。所有権の問題は、より実務的な問題なのです。
しかし、これは専門知識への敬意でもあります。なぜなら、セキュリティの問題が発生した場合、その構築方法を知り、複雑さを深く理解している人々が修正を行うことを私たちは望むからです。この所有権は、権限ではなく専門性を重視する、高い回復力を持つ組織につながります。あなたがそれを所有し、構築し、専門家であることが、より効果的であるように思われます。
セキュリティオーナーシップモデルと意思決定プロセス
これがエンジニアリング組織でどのように展開されるかというと、私たちはサプライズを望みません。毎年、サービスチームに対するAWSセキュリティの期待事項があり、私たちは取り組むべき大きな課題を特定し、これは非常に計画的な作業です。また、飛び込んで適切な人々を部屋に集める必要があるセキュリティの問題も発生します。エンジニアリングチーム、通常はシニアSDEとマネージャーがそのプロセスを主導します。彼らがリスクの評価、顧客体験への影響、そしてその緩和方法を主導します。
サービスオーナーとして、このリスクをどのように、いつ緩和または軽減するかを決定でき、適切な答えを得て適切にコミュニケーションを取るために多くの人々とレビューを行います。最も素晴らしい点は、セキュリティチームがツールを所有し、組織全体のセキュリティ上の発見事項を把握しているため、それらのパターンをツールに組み込んで、他のすべてのチームを支援できることです。これにより、セキュリティレベルを継続的に向上させるフレームワークが作られます。
具体例を見てみましょう。Log4jは少し使い古された例かもしれませんが、Heartbleedと同様、過去10年間に発生した重大なインターネットの脅威の一つです。Securityチームは、ゼロデイ脆弱性やオープンCVEが発見された際に、その脅威とリスクを特定し、優先順位付けを行います。Log4jの場合、私たちは潜在的な影響の深刻さを認識しました。Javaカーネルのホットパッチを作成したのはEC2チームやOpenJDKチームではありませんでしたが、私たちはそれらのパッチと修正を全てのエンジニアリングチームに広く伝えました。
これは、コードパスのどこに脆弱性が存在する可能性があるかを理解しているサービスの専門家と、私たちがリスクを評価する際の連携です。チームが私たちに寄せる信頼は、リスクレベルの判断が正確であることを必要とします。なぜなら、優先度が低ければ、計画されたSprintまで待つことができるからです。Log4jのインシデント中、サービスオーナーとして、私は最も重要なシステムを第一に、第二に、第三に対処すべきかを判断しなければなりませんでした。Billにはそれを判断することはできません - 私が自分のサービスについて知っている必要があり、そのおかげで時間に基づいてアップデートを段階的に行うことができました。
組織内のチームにこれをどのように伝えるかについて話してきましたが、ここでAWSが最近始めたBoard（取締役会）へのコミュニケーションについて触れたいと思います。Securityは私たちが重視し、伝えてきたものですが、Boardにも私たちの価値観に共感してもらいたいのです。Securityが私たちの文化にどのように組み込まれているかを実践的に見てもらいたいのです。私たちは常に、新しいサービスや組織のビジョンなど、すでにBoardに報告している内容を確認し、Securityについても言及するようにしています。なぜなら、Securityはその取り組みの一部となるからです。
二つ目は、新しいテクノロジーについて話すことです。Generative AIのようなトピックを議論する際は、会社全体でAIに関連する全てのものに組み込まれているSecurityの懸念事項、期待、戦略について洞察を提供するようにしています。三つ目は時事問題です - ニュースで取り上げられる出来事について、私たちの組織がどのように考えているか、同様のインシデントを防ぐために先を見据えて積極的に取り組んでいるか、あるいはそれらにどのように対応したかを共有します。
例えば、このような出来事が私たちが取り組んでいることで起こらない理由や、私たちがどのように対応したか、あるいはお客様にどのように説明したかについて議論することがあります。これらは彼らが学びたいと思う興味深いことです。このセクションをまとめるにあたり、皆さん一人一人に、自社のCore Valuesを大切にしていただきたいと思います。これらは私たちが重視してきたことですが、組織に合った方法で実施しなければ、同じような効果は得られないでしょう。
ソフトウェア開発ライフサイクルにおけるセキュリティの組み込み
それでは2番目の柱である共有された行動について見ていきましょう。先ほど、価値観や規範が行動にどのように影響を与えるかについて話しましたが、ここでは Amazon Web Services で私たちが導入している行動を導くためのメカニズムについてお話ししたいと思います。このメカニズムは、インプットとなるものを確立しますが、私たちが本当に得たいアウトプットは何か、そしてそれらのアウトプットを継続的な改善のサイクルとして確実に得るために必要なツール、導入、検証は何かということです。
お話ししたいメカニズムの1つは、エンジニアリングチームを率いているBridgetから始めたいと思いますが、ソフトウェア開発ライフサイクルについてです。セキュリティに関する行動を、ソフトウェア開発ライフサイクルの特定の部分でどのように実現したいのかを特定することから始める必要があります。なぜなら、最後に行うのでは遅すぎるからです。この点についてどのようにお考えですか？
私たちは、あらゆるレベルでセキュリティを実践しており、それは設計から始まります。通常、設計書があり、私の組織では、アクセス制御、データの所在、分類に関する具体的なセキュリティの質問を追加しました。設計を行うエンジニアに対して、それが小規模な設計を行うジュニアエンジニアであれ、より複雑なシステムを担当するシニアエンジニアであれ、具体的な質問を追加しました。また、この段階でセキュリティチームを参加させることも重要です。デプロイの段階までセキュリティを持ち込まないと、遅すぎて混乱を招くことになります。一貫してセキュリティを組み込むことの方がはるかに効果的です。ここでSecurity Guardianが役立ちます。
私はIdentityシステムを担当していますが、セキュリティについて広範に議論しています。大きな変更を行う場合は通常AppSecを導入し、チームが成長するにつれて、早い段階で脅威モデルを開始し、システムと潜在的なリスクを理解していきます。Amazonでは、エンジニアに自身の脅威モデルを作成させています。彼らは、ビジネスと技術的なコンテキストを持っているため、組織のセキュリティエンジニアが持っていない、システム固有の脅威を特定するのに最適な立場にいます。
私たちはエンジニアに独自の脅威モデルを作成してもらいたいと考えていますが、多くの場合、彼らはセキュリティの専門家とは異なる方法で脅威を考えています。そこで、脅威モデリングに関するガイダンスを提供し、その方法を教えています。新しい機能やAPIを追加するため、システムの進化に伴って脅威モデルも変化していくので、これは継続的なプロセスです。エンジニアが脅威モデルを所有することが重要で、私たちはそれが完全で包括的であることを確認するためにレビューを行います。AWSサービスを利用する顧客やビルダーが脅威モデリングについて考えるのを支援するThreat Composerという公開ツールがあり、これは社内のApplication Securityでも使用しています。
Threat Modelingのプロセスは、全ての段階を通じて進化していきます。Build & Testの段階ではPenetration Testingを行いますが、その前に基本的なチェックのための自動化ツールを使用します。インフラストラクチャのプロビジョニング時には、私たちが許可していないパブリックバケットなどのチェックを行います。私のチームでは、パブリックバケットをチェックするためのサービスであるAccess Analyzerを使用しています。リソースのプロビジョニング時に適切な設定を確保することで、セキュリティを左にシフトさせています。これらの自動化は全てAppSecレビューに貢献し、エンジニアとAppSecエンジニアの両方に情報を提供することで、デプロイ直前の一括セキュリティレビューではなく、進化的なプロセスとなっています。
あらゆるレベルでセキュリティを組み込むことは本当に有効です。ただし、全てのレベルで実装しなければならないと考える必要はありません。一つのレベルから始めればいいのです。例えば、設計文書にいくつかの質問を追加するだけでも、あるいはビルドフェーズに一つのテストを組み込むだけでも構いません。
AWSのビルダーが現在、自身でThreat Modelingを行う責任を持つようになった理由について、お話しさせてください。 これは何年も前のre:Inventまで遡る話です。あるサービスチームが、コンソールで良くないカスタマーエクスペリエンスを引き起こすような機能をローンチしました。COEが開始され、調査の結果、エンジニアリングチームは組織から課されたセキュリティ要件を、単に義務だと感じて実装していたことが判明しました。これは問題のある状況でした。
私たちは、顧客の利益のために必要な場合、エンジニアがセキュリティ要件に対して異議を唱えられるようにする、より良い方法が必要だと判断しました。これはThreat Modelingから始まりました。なぜなら、ビルダーが自身のThreat Modelを所有し、自分たちに固有の脅威を特定することで、何かが自分たちのサービスに適していない場合に効果的にエスカレーションする権限が与えられるからです。彼らは、特定の要件が自分たちのサービスのニーズに合わない理由について、客観的な情報を持って主張できるようになります。
Weekly Security Meetingとセキュリティ問題への対応プロセス
ビルドライフサイクルにおける私の好きな言葉である「エスカレーション」についてお話ししましょう。このスライドにはケーキが表示されていますが、これには理由があります。講演でもお馴染みのEric Brandwineは、AWSとAmazonにおけるセキュリティの重要な声の一人です。彼は特にセキュリティ関連事項について、エスカレーションの重要性を頻繁に強調していました。24時間体制のセキュリティチームがあり、いつでもセキュリティの問題を作成したり、リーダーを巻き込んだりできることを、彼は皆に思い出させていました。
実は私はこの問題をエスカレーションする際、Eric Brandwineまで話を通しましたが、彼は素晴らしい対応をしてくれました。冷静さを保ちながら、お客様にとって最適な解決策を見出し、セキュリティ基準を維持するために的確な質問を投げかけてくれたのです。リモートワーク期間中、私は感謝の意を込めて「escalate」と書かれたケーキを彼に送りました。これは私たちの共有する行動規範や価値観につながるエピソードです。
私たちのチャットでは、エンジニアがリスクや改善点について懸念を示した際、シニアエンジニア、Principal Engineer、SDM、そして私自身も含めて、最初の対応は必ずセキュリティイシューを作成することです。そのセキュリティイシューが作成されると - Amazonはチケットが大好きですからね - 通常のプロセスとして扱われます。Securityチームが関与して質問を投げかけ、リーダーシップも状況を把握します。これらのセキュリティチケットの中には、適切な調査の結果、問題なしとして終了するものもあれば、対策チームが編成されて影響の軽減に取り組むケースもあります。
注目すべき点は、私のチームに入ったばかりの新卒社員でも、気になることを見つけたらセキュリティイシューを作成できるということです。これは多くの企業や組織では一般的ではありませんが、私たちは特にセキュリティに関するエスカレーションを当たり前のこととして扱うよう努めています。私のチームのメンバーは、セキュリティイシューを見つけたら私に通知し、チケット情報を共有して私が適切に対応できるようにすることを知っています。エンジニアが懸念を提起し、新しい発見につながった時は、それを称賛します。エスカレーション、特にセキュリティに関する事項については、誰もが気軽に実践できる文化を作ることが重要なのです。
Director級のポジション、Distinguished Engineer、COEがエスカレーションを推奨するのは当然のことです。私がAmazonでPrincipal Engineerとして働き始めた頃によく耳にしたことですが、私自身も顧客をブロックしているコンプライアンスの問題など、様々な事項についてエスカレーションを行ってきました。年次の社内セキュリティカンファレンスで、私は「Escalating from the Middle」というタイトルで講演を行いました。シニア社員にとってエスカレーションは比較的容易かもしれませんが、大企業のChief Information Security Officerにエスカレーションすることは、中間管理職や新入社員にとっては緊張する場面かもしれません。単に「エスカレーションしなさい」と言うだけでなく、効果的なエスカレーションの方法を教え、権限を与える必要があります。私たちは実例を用いた講演やクラスを提供し、成功したエスカレーションの事例や、情報が不十分だったケース、タイミングが遅すぎたケースなどを紹介しています。また、すべての情報が揃っていなくても、インシデントや重大な問題につながりそうだと感じた段階で注意を喚起する「プレエスカレーション」といった行動も推奨しています。
また、エスカレーションの可能性は休暇時期との相関関係があります。私が教えていることの一つに、エスカレーションバディの存在があります。個人的な用事や休暇で不在にする場合、問題が発生した際に備えて、状況を把握している人が他にもいるよう、すべての詳細をバディと共有できるのです。
エンジニアリングリーダーとして、私はすべてのチームミーティングでセキュリティについて話し合っています。何かを発見したり疑わしいことがあった場合の対応手順を示すスライドを必ず含めていますが、それは単にチケットを作成するだけの話ではありません。その手順をサポートできる親しみやすいシニアエンジニアを指名し、バディシステムを重要な要素としています。 セキュリティに関するオーナーシップモデルが何であれ、セキュリティ問題に対するエスカレーションと対応の手順を確立する際には、それがオーナーシップモデルと整合し、適切な人々が対応に責任を持つようにすることが重要です。これにより、継続的なセキュリティオーナーシップの好循環が生まれ、将来的に同様の問題を防ぐことができるようになります。
最後に紹介したいメカニズムは、経営陣に話を戻すと - 組織のリーダーがトップダウンでセキュリティについてコミュニケーションを取る必要があることについて話しましたが、私たちはWeekly Security Meetingと呼ばれる方法でこれを効果的に実践しています。これは何年も前にCEOのAndy Jassyによって確立されたもので、毎週金曜日にセキュリティ組織とCEOの間でミーティングを行い、セキュリティの問題や将来の懸念事項について話し合います。これは、単にアドホックな問題についてのメールを読むだけでなく、セキュリティが最優先事項であることを示しています。
このメカニズムは非常に包括的です。6時間ごとの24時間体制のオンコール当番があり、Director レベルの担当者がそのシフトで発生したすべての問題をレビューします。このDirectorは、セキュリティが適切に優先されていないケース、文化的な問題、リソースの問題、さらなる調査が必要な事項などを特定できます。これらの項目は月曜日のミーティングで集められ、そこですべてのサービスチームが参加し、水曜日までにCorrection of Error（エラー修正）文書の作成を依頼されます。
私たちはこれらの文書をレビューし、深いオーナーシップ、完了までの道筋、予想される完了日、軽減戦略が確実に含まれているようにします。組織では時にトレードオフが必要になり、期日の延期や機能のスキップといった決定を下すことに不安を感じる人もいるかもしれません。シニアリーダーシップは、セキュリティを優先したり、リスク評価に基づいてタイムラインを調整したりすることを安全に行えるよう、これらの状況の解決を支援できます。このプロセスは専任チームによってサポートされており、即興的なものではありません。
このプロセスの利用者として、私はサービスチームがCOEを作成し、顧客への影響を明確に説明し、データを収集し、軽減への道筋を定義する責任を負っていることを証言できます。このプロセスは非常に成功を収め、AWS Identityを含む他のサービス領域でも、若干軽量化されたバージョンではありますが、同様のミーティングが採用されています。
このようなミーティングの素晴らしい点は、一度に全ての専門家の視点を集められることです。私はそのミーティングを活用して、「ここで判断が必要です。この質問に答えましょう - このように対処しますが、他の部分に影響があるかもしれません」と言い、全員がそれが正しい答えだと同意するか、過去に上手くいった代替案を提案します。このようにミーティングを活用しており、非常に効果的です。興味深いのは、これはAWS Securityがidentityチームや他のサービスチームに指示したものではありませんでした。彼らはCEO LWSMミーティングに時々参加し、うまくいかないことがあった際に、その成功を模倣して自分たちのチームをより良く準備するために、独自の週次セキュリティミーティングを開始することを決めたのです。
正直なところ、私たちは今ではそのミーティングにあまり参加しなくなりました。なぜなら、私たちの組織からの指示なしに、会社全体でこのような取り組みが自然に広がっていくのを見るのが非常に興味深いからです。営業組織にも、Solution Architect、Professional Services、Technical Account Manager、そして実際の営業担当者を含むミーティングがあります。営業組織が独自のセキュリティエンゲージメントモデルとセキュリティオーナーシップを持っているというのは、本当にユニークだと思います。素晴らしいことに、私たちが人々に責任を持たせる必要はなく、彼ら自身が責任を持つようになっています。
これらのメカニズムを持つ最後の柱について確実にお話しするために、いくつかのスライドを飛ばしたいと思います。先ほど言及したように、どのメカニズムにもツールの採用と検査があり、しばしば検査が忘れられがちです。そのため、導入したメカニズムを必ず検査し、望んでいる成果が得られているか確認してください。Jeffが言うように、プロセスのためのプロセスになってしまうのは致命的だからです。
この柱について最後に忘れてはならないのは、Amazonが長年行っていなかったことです。私たちはソフトウェア開発エンジニアやソフトウェア開発マネージャーの職務指針にセキュリティを組み込んでいませんでした。エンジニアたちが私たちのところに来て、セキュリティについて非常に気にかけているのに、昇進を考える際にその仕事について話せないと言い始めました。これは基本的なことであり、皆さんの組織で今年中に実行できる具体的なアクションです - セキュリティを職務指針に組み込むことです。
Guardiansプログラムによるセキュリティ知識の普及
私たちはこのように実施しています：若手のソフトウェア開発者の役割では、自分のアプローチがセキュリティ基準を満たしているか疑問がある場合は、より上級者にエスカレーションするよう定めています。シニア開発者については、重要なビジネスやセキュリティリスクをもたらす可能性のある本質的に困難な問題を特定すると定めています。これらはシニアエンジニアが、サービス全体を見渡して、より複雑な問題とその対処方法を特定し、より多くの曖昧さがある可能性がある場合を指します。マネージャーについては、セキュリティを含む全体的なアーキテクチャとソフトウェア品質を改善する取り組みを優先するよう定めています。これらの職務指針には、人々がキャリアを進め、昇進する際の基準となる側面が含まれているため、非常に重要です。
最後の要素について掘り下げていきたいと思います。これは決して重要性が低いわけではありません - それはKnowledgeです。先ほど申し上げたように、私たちのValues and Normsは個人が何を重要視するかを判断する助けとなりますが、Knowledgeはその目的を達成するための手段なのです。ここで、私たちのGuardiansプログラムについてお話ししたいと思います。皆さんの中にも、私たちと同じような課題を抱えている方がいるかもしれません。つまり、Security Teamのメンバーよりもソフトウェアエンジニアやビルダーの数が圧倒的に多いという状況です。新しいサービスの立ち上げや新機能の実装のたびにSecurity Teamのレビューが必要となり、そのサービスのコントロールに関して、チームが考慮していなかった問題点を指摘することになっていました。
そうなると、サービスチームに差し戻してやり直しを依頼しなければならず、それには時間がかかります。私のチームの創造力豊かなメンバーにこれを依頼したところ、楽しいアニメーションをたくさん作ってくれました。私たちが取り組んだのは、エンジニアリングチームが早い段階からセキュリティについて考え、期待される要件を理解できるようにすることでした。そうすることで、彼らが自分たちのサービスを構築する際に、設計段階からセキュリティを考慮し、コードを1行も書く前にThreat Modelingに取り組めるようになります。
現在、組織内には5,000人以上のアクティブなエンジニアがいて、それぞれのサービスチームで訓練を受けています。私たちの目標は、各サービスチームに少なくとも1人のトレーニングを受けた人材を配置することです。サービスチームというのは、Two Pizzaチームのことですが、数千のチームにまたがる組織内の各マネージャーの下に、セキュリティについて考え、チームのセキュリティ意識を高めるトレーニングを受けた人材が少なくとも1人いるということです。
この取り組みの結果は、かなりインパクトのあるものでした。AECレビューで特定される、ローンチをブロックする指摘事項が22.5%減少しました。これを数字で見ると、非常に大きな意味を持ちます。年間で約21万作業日の節約になるのです。毎年1万件以上のローンチがあり、その指摘事項を22%以上削減できることは、新しいサービスをより早くお客様に提供できることに大きく貢献しています。現在では、高いセキュリティ基準を維持しながら、予定通りにローンチできるようになりました。これにより、セキュリティレビューの完了までの時間が26.9%短縮されました。
エンジニアリングの観点から言うと、私は2018年からエンジニアリングチームを率いていますが、以前はAECレビューがうまくいくことを祈るだけでした。しかし今では、多くのチームにSecurity Guardianがいるため、スムーズなプロセスになっています。Security Guardianの素晴らしい点は、チームのビルダーであることです。彼らは若手エンジニアやシニアエンジニアと協力し、セキュリティの視点と知識を提供します。外部からAECエンジニアが来るのではなく、チームの知っている人、話せる人、協力できる人がいることで、心理的安全性が生まれ、メンバーは仲間とセキュリティについて気軽に話し合えるようになっています。
すべての開発者は基本的なセキュリティの指導を受けますが、Guardiansはより深い研修を受けます。彼らはAECエンジニアのような存在で、レビューを行うための訓練を受けています。自分の仕事を自分でチェックすることはできませんが、基本的にサービスチーム内の副官のような存在です。これはスケーリングのための機能です。私たちは、フィールドコミュニティ、ソリューションアーキテクチャ、ProServやTAMコミュニティにもGuardiansを配置しています。なぜなら、彼らは顧客とともにコンテンツ、ソリューション、実証実験を作成しているからです。私たちはAPIの背後にあるサービスであれ、セキュリティレビューが必要な何かを構築する際であれ、コードを作成して出荷するので、営業組織にもGuardiansがいます。
同様のことを実施することを考えている場合は、達成したい目標のビジョンを設定する必要があります。私たちのビジョンは、開発ライフサイクル全体を通じて、Security by Designによってお客様を常に満足させるセキュリティオーナーシップを育むことでした。これがビジョンとなった理由は、開発ライフサイクル全体を通じて人々に本当の意味でセキュリティについて考えてもらうことが難しいからです。私のビジョンは、それが自然に起こることになり、私たちはそれを育むだけの存在になることでした。
このプログラムの初期に私たちが間違えたことの1つは、多くのAECレビューを経験したシニアエンジニアにパイロットプログラムを実施したことでした。彼らはすでに何をすべきか知っていたため、非常に成功しました。しかし、新しいチームができた場合はどうでしょうか？AWSは非常に急速に成長しています。そのチームにAEレビューを経験した人が誰もいない場合はどうでしょうか？チームがジュニアSTEだけで構成されている場合はどうでしょうか？求めている最終的な成果に影響を与えるセキュリティに関連して、これらの人々が行うべき最も重要なことは何かを考える必要があります。
今日、私が推奨するとすれば、Threat Modelingを強調します。彼らにThreat Modelingを教育し、1行のコードを書く前にチームがThreat Modelを構築することを確認する以外の期待を持たないようにします。これは大きな影響を与えます。なぜなら、それによってオーナーシップと知識がもたらされるからです。そして規範が生まれ始め、それが会話を助けます。なぜならThreat Modelingは孤立して行われるものではなく、多くの場合チームの取り組みであり、それを完成させるには異なる視点が必要だからです。
小規模から始めて、人々に時間を費やしてほしい最も重要なことは何かを考えてください。
2番目に強くお勧めしたいのは、コミュニティの力に注目することです。Culture of securityがセキュリティ成果向上の「何を」だとすれば、コミュニティの関与は「どのように」にあたります。すべては体験から始まります。Guardianたちがトレーニングを受け、シャドウイングを行い、逆シャドウイングを実施し、最初のThreat Modelをサポートする際の体験に焦点を当てます。人々からのサポートを感じられ、相談できる窓口があり、彼ら専用のOffice hoursを通じてリソースを得られる、そんな最高の体験を提供するのです。体験が良いものであれば、彼らは行動を起こします。そして行動を起こすことで、自分では達成できないと思っていたことを、コミュニティとして一緒に成し遂げることができるのです。思いもよらない成果を上げることができれば、彼らは周りの人々 - 同僚や上司、そしてコミュニティの他のメンバーにそれを伝えるでしょう。
そうすると、周りの人々は、このコミュニティのメンバーになりたい、トレーニングを受けたい、あるいは自分の組織内で人々により積極的に参加してもらうための支持者になりたいと感じるようになります。これは彼らが目にする成果があるからです。私が言いたいのは、望む成果にあまりにも注力しすぎないということです。小さな成果を1つ選び、コミュニティに焦点を当て、そのコミュニティの強化に本気で投資してください。そうすることで、より短時間で大きな影響力を生み出すことができます。
では、私たちが持つコミュニティについてお話しします。セールス組織には約46の技術分野のコミュニティがあります。私は2012年か2013年にセキュリティのコミュニティを立ち上げました。おそらくストレージの次に1番目か2番目でした。長い間、セキュリティの分野のコミュニティは最大規模を誇り、1000人以上のメンバーがいました。その多くはSolution Architectsですが、全員がスペシャリストのSolution Architectsというわけではありません。多くは、担当アカウントや顧客に関わる一般的なSolution Architectsです。これは水平的なコミュニティなので、どのセールスセグメントや組織のどの部門に所属しているかは関係ありません。
このコミュニティは、これまでの協働スタイルが通用しなくなったパンデミック期間中も、組織再編を経ても、そしてビジネスの大規模な成長を通じても、非常に強固な仕組みとして機能してきました。顧客にとって最優先事項である適切なセキュリティの実現について、彼らがあなたを助け、理解するための方法となっています。このコミュニティには、技術的な社内サミット、セキュリティサミット、Office hoursやLunch and learnのような現場での地域イベントなど、さまざまな形での協働があります。社内セキュリティカンファレンスは、人々が最も話したがり、関心を持つイベントの1つとなっています。
最後のアドバイスはコミュニティに関することですが、トレーニングを受けるビルダーたちのマネージャーやリーダーにデータを提供することを忘れないでください。組織全体のディレクターに向けて、彼らの組織のGuardiansに関するデータを提供しています。これは、新しくトレーニングを受けたGuardiansの数、サポートしたセキュリティ案件の数、進行中の案件数、そしてSecurity Engineerによって評価された平均品質スコアを示しており、会社全体と比較して自己評価できるようになっています。また、それらのレビューで特定された問題点の平均数も伝えており、自分たちの組織やAWS全体と比較できるようになっています。
私たちは、期待以上の成果を上げた人々を称賛しており、その効果は明らかです。このディレクターにメールを送るように指示したわけではありませんが、これは彼らが即座に送ってくる多くの例の一つです。このメールには「プログラムに参加してくれた皆さんに感謝します。Securityは私たちの最優先事項です」と書かれています。これは私たちのリーダーたちが使う共通の言葉であることがわかります。このようなプログラムは、私たちが適切にSecurityを実践していることを確認するためのものです。彼は個人の名前を挙げて称賛しています - これは、入社して数年の若手やSTEにとって、おそらく今までディレクターと話したことがない人でも、直接自分の名前を挙げられ、マネージャーにもそれが伝わるというのは、とても素晴らしいことではないでしょうか。これは非常に強力な効果があります。
先ほどお話したフライホイールについて考えると、これはそのフライホイールをさらに加速させるものです。データを活用することで、人々は自分たちのパフォーマンスについてフィードバックを得る機会を持ち、改善点や注力すべき領域を知ることができます。このフィードバックは、彼らが毎日行動を継続するモチベーションとなる認識を提供し、達成不可能と思われていたことを実現する手助けとなります。
始めるためには、ビジョンを設定し、最も重要なことを特定し、チームにその重要性を理解させ、コミュニティを構築し、そしてそのコミュニティを評価、報告、認識し、組織内の人々がそれを実践できるようにすることです。もしあなたがAWSの1/100の規模の会社にいたとしても、これらの人々を個別に認識することはできないでしょう。そのため、彼らのリーダーが認識できる拡張可能な仕組みを確立することが重要です。なぜなら、それはさらに強力な効果をもたらすからです。
セキュリティカルチャー構築のまとめと今後の学びの機会
まとめると、Securityカルチャーを育むために、3つの重要な領域について考える必要があります。各ピラーから1つのことを選んでください：価値観と規範、共有される行動、組織内のすべてのチームに知識を広めるメカニズムです。これにより、私たちが話し合った4つの成果につながります：Security ownershipの確立、Psychological safetyの実現、High-velocity decision makingの実現、そして最終的にはSecurityがビジネスを真に可能にする要因となり、これは非常に強力な効果をもたらすことができます。
ここで話し合ったリソースやその他の関連リソースにアクセスしたい場合は、「How AWS sustains a strong culture of security」というウェブページを作成しました。画面に表示されているURLをご覧ください - /security/culture-of-securityです。そこでは、独自のGuardiansプログラムを構築する方法についてのブログをご覧いただけます。私たちが学んだいくつかの教訓についても、より詳しく説明されています。
もう1つの学びの方法として、AWS re:Inforceへの参加があります。コミュニティと人々の交流について話す際、これはAWSのセキュリティに特化したカンファレンスの原点であり、セキュリティに関心を持つすべてのお客様が一堂に会して、学び、成長し、ネットワークを築く場となっています。今年は6月16日から18日まで、Philadelphiaで開催されます。私たちも参加しますので、皆様にもぜひお越しいただければと思います。お時間をいただき、ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion