■プロフィール
アマゾンウェブサービスジャパン合同会社 セキュリティソリューションアーキテクト
Tatsuya
AWS での業務内容とこれまでのキャリアを教えてください
Tatsuya：
AWS を利用、あるいは利用を検討しているお客様は、様々なセキュリティの課題を抱え、解決方法を模索していらっしゃいます。私はセキュリティ専門のソリューションアーキテクトとして、その解決をご支援するのが主な役割です。意外かもしれませんが私自身が AWS のセキュリティサービスの概要を説明する機会は多くはありません。むしろ AWS のセキュリティへの取り組みやセキュリティ関連サービスというツールを活かして、どのように組織のセキュリティをあるべき姿に近づけていくか、どうすれば運用が回るのか、クラウドのセキュリティに懸念をもつ経営層の不安をどのように解消していくかなど、技術をベースにしながらも、組織や人に関連するテーマへ取り組むことが多いですね。この背景には、セキュリティというのは単にサービスやツールを使えばそれで終わりということではなく、取り組みを組織的なものにし、それを支える人材を育成し、継続的に運用可能なメカニズムを整備することが重要である、ということがあるのかなと思います。
今でこそこの仕事をしていますが、私自身は最初からセキュリティをやってきたわけではないんですよね。過去の業務経験の中でセキュリティを意識することがたまたま多く、結果的に専門でやるようになったという感じです。大学でコンパイラの研究をする研究室に所属しながら、アルバイトで学科 IT 管理をしたことなどを通じて「コンピュータやネットワークって面白い」と思い、新卒で日系 SIer に入社しました。配属先は自主事業部門だったのですが、体制が小さく、企画・営業もアプリ・インフラも見よう見まねで全部やっていました。まったくもって上手にやれていたとは思いませんが、結果的に様々な視点でセキュリティを考える基礎になったなと感じます。
初めて関わったシステムは、銀行や証券口座の ID/PW をお預かりして資産情報をスクレーピングし、まとめて表示するサービスだったのですが、秘密鍵を物理的に守る耐タンパ性を備えた HSM (Hardware Security Module) を利用していました。キャリアの最初に HSM をいじれたのは「セキュリティの作り込みそこまでやるのか」と考えさせられる貴重な経験でしたね。また、お客様の ID/PW つながりで Digital Identity に関連する事業に関わったのですが、今や世界中で使われている OpenID Connect や JWTの仕様を、すぐそばに座っている大先輩がグローバルの標準化団体で策定していく姿を目の当たりにし、少しでも追いつきたいと思って試行錯誤を重ねる過程でキャリアを通じた得意領域ができました。最近、デジタル庁の ID・認証関連の有識者会議に AWS として参画しているのですが、その経験のおかげですね。また前述の自主事業の後はWeb診断を楽しくやっていたのですが、縁あって黎明期の OT セキュリティ領域で工場・プラントや発電所を対象にしたセキュリティを考えたり、IoT やコネクテッドカーなど組み込み機器を含むセキュリティ領域の事業立ち上げに関わりました。直前はオシロスコープで回路を流れる通信を解析したり、回路に半田付けして不揮発メモリから秘密鍵を抽出して API を呼び出すようなセキュリティ診断をやっていたのが、今はどっぷりクラウドです。ずいぶん変わりました（笑）
AWS のお客様は本当に多様な業界・業種にわたります。そのためクラウドに直接は関係ないように見える経験も、どこかで結びついてくることは少なくありません。昔は自分のキャリアの積み方に一貫性がない、と不安に感じていたこともあるのですが、今はポジティブに、意外に過去の経験がお客様のセキュリティ課題を解決するために役にたつものだ、と感じつつ業務にあたっています。セキュリティは一言で表すことのできない広い領域です。それを専門として取り組むに至る経験の積み方も千差万別、皆違うバックグラウンドを持っていることそのものに価値があると感じています。
システムのセキュリティを強化するために意識すべきポイントはありますか？
Tatsuya：
「これを入れておけば大丈夫」という全てに効くセキュリティ万能薬をご紹介できればどれほどよいか、と常々思っていますが、残念ながら殆どの場合はそうはなりません。セキュリティの考え方として「他の部分が十分セキュアだったとしても、弱い箇所が１つあると、そこが起点となって守るべき資産に対して影響が広がっていく」というようなものがあります。つまりセキュリティというのはバランスよく総合的に高めていくことが大切、ということです。
そのために、ベースラインアプローチとリスクベースアプローチの２つを意識できると良いですね。
ベースラインアプローチというのは、先人たちの経験に基づいて汎用的に役立てることができるセキュリティ観点（権限管理や認証、暗号化など）を予めまとめたもの、つまりベストプラクティスを利用する手法です。幅広い観点というものを自分で思いつくのは正直大変ですし、参照できるものがあるというのは助かりますよね。著名なものでは、NIST Cyber Security Framework (CSF) や、ISO 27000シリーズ、カード業界の PCI-DSS、あるいは日本の金融機関にいては FISC 安全対策基準など、様々なセキュリティガイドライン／コンプライアンスプログラムが存在しています。AWS 自身も、サービスを提供するためのインフラストラクチャの統制において様々なガイドライン／コンプライアンスプログラムを考慮しています。後述しますが、AWS が長年お客様を支援してきた過程で得た知見をまとめた ”AWS Well-Architected Framework - セキュリティの柱” というベストプラクティスも、お客様のワークロードのセキュリティを高める観点として活用できますし、AWS のセキュリティ高めるために様々な用途で活用されています。
AWS Well-Architected Framework - AWS Well-Architected Framework (amazon.com)
一方、皆様のビジネスが拡大し、提供する価値が増えるにつれて、システムは複雑化し、ユースケースは増加していっています。そういったものにベストプラクティスをそのまま適用しようとしても、いまいちフィットしないと感じることはありませんか？それぞれ特性の異なるシステムならではのセキュリティ脅威を十分考慮するために有効とされているのが、リスクベースアプローチ（あるいは脅威ベースアプローチ）です。リスクベースアプローチでは、どのような資産を管理・保護したいか、どのような脅威が想定され、どのような問題が起きる可能性があるのか、を明らかにしながらリスクへの対処方法と優先順位を決定するため、お客様が「限られたリソースで最大の改善効果」を得るために有効な手段です。とはいえ、リスクベースアプローチには一定の専門性が必要だったり、実施負荷が高くなることもあります。この手間や運用を考えると、開発ライフサイクルの後半よりも相対的にコストが少なくて済む設計フェーズで実施し、問題を早めに特定して対処できるようにしておくことが効果的です。机上では「こうやりましょう」と書いてあっても、いざ実際にやってみると大変だったり、うまくいかなかったりするものです。その際は、実践的なナレッジを身につけるための AWS の教材やワークショップも参考にしてみてください。
SEC01-BP07 脅威モデルを使用して脅威を特定し、緩和策の優先順位を付ける - AWS Well-Architected Framework (amazon.com)
このようにベースラインアプローチを利用して幅広い観点で素早くセキュリティの底上げを図りつつ、お客様のワークロードの特性を考慮したリスクベースアプローチで最適な対策と優先順位を考えていく。２つのアプローチを適材適所で使い分け、バランスよく効率的・効果的にセキュリティを高めていけるとよいですよね。
最近のセキュリティのトレンドについて教えてください
Tatsuya：
話題になるようなセキュリティのトピックには、その背景としてビジネスの目的や社会動向の変化が密接に関連していると思います。セキュリティのことだけを考えているとついつい陥りがちなのですが、セキュリティはそれ自体が目的ではなく、ビジネスを安心して推し進めていくための手段である、と捉えるとよいでしょう。
例えば、近年は生成 AI が目覚ましい進歩を遂げており、AWS でも Amazon Bedrock を提供しています。生成 AI をビジネスで活用する取り組みが高まるに連れて、生成 AI を安心して利用するためのセキュリティに関心が寄せられていくわけです。RDBMS を利用する Web アプリケーションに SQL インジェクションというセキュリティ観点があるように、生成 AI 特有のプロンプトインジェクションという観点も出てきています。一方、新しいことばかりではなく、従来のセキュリティの考え方がそのまま役にたつ、ということも同時に整理されていっています。
生成 AI をセキュアにする : 生成 AI セキュリティスコーピングマトリックスの紹介 | Amazon Web Services ブログ
数年前から語られることが増えたゼロトラストという考え方でも同様です。おおまかに言うと、従来からあるネットワークの境界（IP アドレスや Firewall など）に基づいたアクセス制御だけでなく、アクセスする人やマシンが誰か・どんな状態かというアイデンティティ情報も組み合わせ、より動的に都度チェックをして IT システムをセキュアかつ便利に使えるようにしよう、という考え方です。典型的なものでは、以前はオフィスなど特定のネットワークの場所に基づいてデータへのアクセス制御を行っていたものが、COVID-19や働き方の多様化など社会情勢の変化によって、さまざまな環境からリモートアクセスが求められるようになったことで、まさにゼロトラストの考えに基づいた重要なユースケースになっているわけです。一方、技術要素自体は真新しいものではなく従来のセキュリティの考え方が有効です。実際、AWS はゼロトラストという言葉が話題となる以前から、AWS を操作するために毎日世界中のお客様が利用している API の保護をネットワークに依存しない形で実現しています。言葉の話題性に関わらず、お客様にとって価値あるセキュリティを提供することが重要というわけです。
AWS でゼロトラストを実現するためのアプローチ(AWS-39) / 資料
サプライチェーンのセキュリティというキーワードも最近聞くようになりました。昨今のシステムは高度化し、オープンソースやサードパーティーのソフトウェアコンポーネントが複雑に絡み合って構成されています。自分たちが開発し詳細を把握できているソフトウェアだけでなく、世界の誰かが開発しているサードパーティーのソフトウェアに依存しているわけです。そのため、依存関係にあるサプライチェーン全体視点でセキュリティの状態を可視化・追跡してくことが、最終的に稼働するシステムのセキュリティ維持に欠かせなくなってきたという背景があります。システムで利用しているソフトウェア一覧を可視化したソフトウェア部品表、つまり SBOM (Software Bill of Materials) を介して、開発パイプラインやテストツールあるいは脆弱性管理ソフトウェアなどを連携させ、開発ライフサイクルを通じてセキュアな状態を維持していく取り組みも広がっています。
Amazon Inspector の 3 つの新機能により、ワークロードの脆弱性スキャンの範囲が広がります | Amazon Web Services ブログ
ランサムウェア対策は一番有名かもしれませんね。IPA が毎年発表している情報セキュリティ１０大脅威 ２０２４の組織向け脅威で第１位になっています。このランサムウェアに対抗するための著名な取り組みの１つに、米国政府により組織され、AWS をはじめとした複数の企業が関わる Ransomware Task Force (RTF) にて検討されたセキュリティガイドラインがあります。従来からある汎用的なセキュリティベストプラクティス CIS Control に沿って、ランサムウェアに対して特に有効なセキュリティ対策を整理したものとなっています。さらに AWS は、これらの対策を AWS 環境で具体的に実現するための指針を提供する “AWS Blueprint for Ransomware Defense” を公開しています。皆様の大切なデータを保護するためにぜひご活用してみてください。
このようにセキュリティというのはビジネスニーズや社会の変化を受けて、新しい考え方が生まれたり、従来の考え方を新しい視点で再整理したり、という側面を持ちます。トレンドだから取り組むのではなく「トレンドの背景」にあるユースケースの変化をつかみ、自社がビジネスを安心して推し進めるために役立つセキュリティは何かを意識していくことが、取り組みの検討や優先順位づけに役立つのではないでしょうか。
AWS上のシステムにおいてセキュリティを改善させるためにどうすればいいか教えてください
Tatsuya：
まず、AWS には、AWS とお客様が互いに協力し、システム全体で優れたセキュリティを実現していく、責任共有モデルの考え方があります。「セキュリティは最優先事項」という考えに基づいて AWS が提供する堅牢な土台の上に、お客様固有のセキュリティ統制を載せて、互いに協力して目標を達成しようというものです。この考え方を活かし、お客様は AWS にセキュリティを任せる範囲を積極的に増やして楽をしていただき、その分ビジネスへフォーカスしていただきたいなと思います。
典型的な例としては、仮想マシン、つまり OS から上のセキュリティ確保はお客様にて実施する Amazon Elastic Compute Cloud (Amazon EC2) 活用から、コンテナ、あるいはサーバレスなど AWS がセキュリティを管理する範囲がより広いマネージドサービスの活用にシフトすることが挙げられます。
お客様がセキュリティを管理し高めていく必要がある場合でも、AWS が備える、優れたセキュリティの実現に不可欠な「高い可視性」と「自動化」という性質が役立ちます。オンプレミスでは各ノードやアプリケーション、ネットワークの状態・設定を常時把握・ログに記録し、セキュリティ観点で監視し続けるのはそれだけで一苦労で、そこから対策に繋げる時は人海戦術、という場合もあるのではと思いますが、AWS が提供する「高い可視性」と「自動化」はこれを効率的かつ大規模に実現可能にします。例えば AWS 環境では「いつ、どこで、だれが、どのような操作をしたか」を記録し、そのログを横断的に収集・保存してセキュリティ分析に役立てることができます (AWS CloudTrail)。AWS 環境で稼働するマシンの OS と様々なソフトウェアの脆弱性を把握する仕組みを素早く構築し、効率的に対処に繋げていくことができます (Amazon Inspector)。お使いの AWS 環境の構成を変更する過程で生じるセキュリティ設定不備を、セキュリティベストプラクティスに基づいて大規模かつ自動的にチェックし、同じく効率的に対処へ繋げていくことができます (AWS Security Hub)。つまり、AWS を利用すること自体が、その高い可視性に基づいてセキュリティ改善に取り組み、自動化も組み合わせて対処までの時間と必要なリソースを削減し、その分を別の施策に充てることができるメリットがあるわけです。
また、広い目線でどのようなセキュリティ対策をすべきかを考える際には、いま「できていること／いないこと」を明らかにすることが大切です。その道標となるのが先ほどご紹介した ”AWS Well-Architected Framework – セキュリティの柱” です。ベストプラクティスの観点に基づいて自己問診、あるいは AWS 担当者と対話しながら取り組み状況を可視化する ”AWS Well-Architected Review” によって、セキュリティ課題を明らかにし、改善に繋げていくことができます。いわば AWS を利用したシステムの健康診断のようなものであり、チェックと改善とを継続的に繰り返すことで、セキュリティを維持向上させていくのに役立ちます。
一方、「セキュリティへの取り組み自体を始めたばかりで、何からやればいいか分からない」というお客様もたくさんいらっしゃいます。そのような場合、まずは「厳選したセキュリティ施策」をスタート地点として始めてみるのも良いでしょう。
最初にやるべき AWS セキュリティ設定 10 のこと | AWS Webinar (awscloud.com)
最後に改めてお伝えしたいのですが、考慮すべきセキュリティ観点というのはクラウドだからといって全く違うものではなく、むしろ殆ど同じです。そして AWS はセキュリティを効率的かつ継続的に改善することを助けるサービス・ツールや、ナレッジを提供しています。ぜひ AWS を活用してセキュリティ改善に取り組み、お客様のビジネスを一層加速させていっていただきたいなと思います。その際に困ったことがあれば、私のようなセキュリティ専門のソリューションアーキテクトにお気軽にご相談ください！
Amazon WoW Careersについて
Amazon WoW Careers は、IT 技術職で働かれている方とアマゾン・アマゾン ウェブ サービス（ AWS ）社員（技術職リーダー・リクルーター）を繋げるネットワーキング・プラットフォームです。
・IT技術職で働かれている主に女性の方
・技術職に興味があり、これから学びたいと考えている女性の方
上記いずれかに当てはまる方、Amazon WoW Careers の取り組みにご興味のある方はぜひこちらのウェブサイトにお越しください！
