SHIFT EVOLVE『Top AWS Ambassadorsに訊くセキュリティ (AWSぶっちゃけ討論会 vol.1)』レポート
はじめに
今回レポートするのは9月30日に開催されたSHIFT EVOLVE『Top AWS Ambassadorsに訊くセキュリティ (AWSぶっちゃけ討論会 vol.1) 』についてです。
Top AWS Ambassadorsとは、AWSのサービスや技術に関する深い知識と経験を持ち、コミュニティに対して積極的に情報を共有し、教育活動を行っている方々です。
こんな機会は2度とないということで絶対見なきゃと思い、視聴しました。
今回のイベントはYoutubeでも見ることができます。題名にセキュリティとついてはいますが、AWS上のセキュリティ設計、運用に携わっている方だけでなく、
自社開発でAWSを使用されている方
事業会社でAWS上での開発を外部へ委託されている方
AWS上にアプリケーションを開発しているアプリケーションエンジニア(サーバサイド、フロントエンド、設計者問わず)
オンプレミスで設計構築経験がありAWSのクラウドエンジニアへキャリアチェンジしたい方
など幅広い方々に学びのある内容になっております。ぜひご覧ください。
https://www.youtube.com/watch?v=GRQLsfQGCOo
Top AWS Ambassadorsに訊くセキュリティ (AWSぶっちゃけ討論会 vol.1)
パネルディスカッション『AWS Top Ambassadorsに訊くセキュリティ』
Speakers
株式会社サーバーワークス マネージドサービス部 カスタマーサクセスマネージャー 佐竹 陽一 氏
TIS株式会社 IT基盤ビジネス推進部 テクニカルエキスパート 横井 公紀 氏
株式会社SHIFT セキュリティサービス部 AWSセキュリティコンサルタント 大瀧 広宣
ここからは、当日のセッションの模様をまとめていきます。
『AWSに言われるががまま各種セキュリティサービスを入れてはみたものの、ちゃんとできているか心配。数年運用してみてどうだった？』
まず最初のトピックです。
横井さん「組織作りが大事」
横井さんは「この質問をしているということは、導入時にはきちんとセキュリティについて議論できていたはずです。運用が始まってから、製品を入れただけで満足し、セキュリティの優先順位が下がり、議論に上がらなくなったのでは？と考えています。」と指摘。
また、「改善するためには組織の仕組み作りが大事であり、セキュリティの運用設計を定期的に見直していく事が必要。例えば新しい環境を作った場合や変更した場合、中間地点でチェックする仕組みや、日ごろから議論したりなどの仕組みがあると良いです。システムだけに頼らず、人の運用が大事だと考えています。」とお話されていました。
佐竹さん「AWSのベストプラクティスをあてはめればよいというわけではない」
これに対し、佐竹さんは「AWSのベストプラクティスをあてはめるだけでなく、組織が作成しているセキュリティの目的を考慮してAWSのセキュリティ設計をしなくてはいけません。」とコメント。
たしかに、医療情報やクレジットカード情報を扱っている事業会社と、 匿名で予約を受け付けているイベントの事業会社とでは扱っている情報のレベルは違うなあと、納得しました。
大瀧「インフラチームとアプリチームではパッチに対しての意識は違うのでは？」
大瀧は「インフラチームはパッチを充てるのが当たり前という感覚。むしろあてなければ何かあったときに自分たちの責任になると考えています。アプリチームはパッチをあてた事でアプリが動かなくなるのを嫌がりますね。DevSecOpsでセキュリティチェックを自動化していたとしても、OSSの部分に脆弱性が出るとパッチをあてるしかなくそれをアプリチームが嫌がりますね。」と、インフラチームとアプリチームにおけるパッチに対する意識の違いを指摘していました。
攻撃を受けた場合も絶望ですが、パッチをあてていない状態で「〇〇日に脆弱性診断をやります」と突然宣告されても絶望ですね。。
『AWSのセキュリティサービスだけで万全？外部ベンダーで補うほうがいいことってある？』
続いてのトピックでは、AWSのセキュリティサービスについてディスカッションが繰り広げられました。
大瀧「外部ベンダー製品の扱いをどうするか」
大瀧は「AWSはエンドポイントセキュリティが弱いため、外部ベンダーで補った方がよいと考えています。」とコメント。
佐竹さん「AWSのサービスだけでセキュリティを担保できるか」
佐竹さんも「実はGuardDutyで検知した時点では遅いです。検知した時点ではやられているという事です。」と述べ、横井さんも「防ぐという意味では、環境を保全するのが大事です。保全対策のために、毎日人が監視するという選択のほかに、サードパーティの製品を入れるというのはありですね。」とお話されていました。
視聴者コメント「Lambdaのようなサーバーレスの方がセキュリティに強い？」
これに対する視聴者からのコメントに対し、大瀧は「EC2などよりは、Lambdaなどのサーバーレスを使った方がセキュリティ的には強いです。」と回答。
佐竹さんは「ただし、完ぺきではありません。InspectorでLambdaの脆弱性チェックをする事もあります。」 、大瀧は「そもそもサーバーレス系のサービスを扱えるならEC2は使っていないですね。」 とそれぞれ補足しました。
「とはいえ、世の中にはEC2で稼働しているケースは多い」という意見で全員一致していました。
情報の扱いをどう考えるか
情報の扱いについて、横井さんは「最小権限の考え方が大事です。それを実現するためにAWS IAM Access Analyzerを使えば、楽に最小権限にできますが、お金がかかるため却下されるケースがあります。」 と指摘。
これに対し、佐竹さんは「Macieもそうです。情報の重要度をタグ付けやアカウント分けしておくと、復旧時に慌てません。」 とコメントされていました。MacieはS3上の機密情報を検知できるので、同じ考え方が適用できるということなんですね。
ログ取得について
ログ取得については、「本番環境DBの監査ログは必ず取る。CloudTrailは有効にする。ログ大事！」と全員お話されてました。
マニュアル作りについて
横井さんは「何かあったときのためのマニュアルを作成しておいた方がよいです。これは自動化のことではありません。例えば地震が発生した場合に避難訓練はしますよね。それをセキュリティの場合もした方が良いということです。(※1)」と述べ、インシデント対応に向けたマニュアル作りの重要性について指摘していました。
佐竹さんは「半年や1年に1回ほど、取得しているバックアップからきちんと復旧できるか訓練をしていた方がよいです。」とお話されていました。
(※1） 有事の出来事を想定し、連絡、バックアップからの復旧、報告などの一連の流れを実施することを「BCP訓練」、セキュリティに特化した避難訓練を「サイバー演習」と呼びます。サイバー演習は様々な専門組織で研究がされており、とても種類が多いです。
下記はIPAが公表している事例の一覧です。
『いざ不正アクセスされたら、情報漏洩が発生したら、何から手をつければいい？日頃から準備できることは？』
続いて、インシデント対応に関して三人それぞれの立場からコメントがありました。
佐竹さん「風通しのよいチーム作りを」
「何か起きたらすぐにエスカレーションできるように、通常の場合と緊急の場合で分けて連絡網を分けて作っている」という佐竹さん。
「GuardDutyで検知した脅威を報告せずに、せっかく取得していたバックアップの期間を過ぎてしまうことがあり、その結果、復旧できなくなるということがあります。担当者が検知を隠さないように、と簡単にいいますが、これを実現するには、担当者が報告しやすい、心理的安全性を考慮したチームビルディングが重要です。AWS Well-Architectedでも組織作りという項目はありますね。」 とお話されました。
問い合わせ力、質問力が重要
また、佐竹さんは「AWSが先日、サポートへの書き方フォーマットを出しました。これは日本のみです。他の国ではありません。質問をするときは、相手が欲しい情報を提供する事が大事です。問い合わせの内容が悪いとAWSからパートナー企業が怒られてしまうのです。そして、何かあったときに初動が遅くなります。そういうのも普段の準備かもしれません。お客様から情報を引き出す質問力も重要視しています。」 と指摘。
これに対し、横井さんは、AWSサポートへの問い合わせの教育をするとともに、普段から「質問する力をつけましょう」と社内に啓蒙しているとお話されていました。
また、サーバーワークス社やTIS社では、AWSへの問合せの体制をしっかり組んでパートナーユーザーからの質問を受け付けているという事をお話してくださりました。
視聴者からの質問
ここからは、視聴者から集まった質問に対して登壇者三人が回答していきました。一部を紹介させていただきます。
『自分自身はPMOとして、AWSを扱う開発ベンダと対峙しています。特に非機能要件に関して「AWSはフルマネージドだから考慮不要」みたいな回答をもらうことがよくあります。どこまでがAWS標準で、どこから各案件でコントロール可能なのか、というのを知りたいです。』
これに対して、大瀧は「AWSに詳しくないお客様が、AWSを使いたいというときによく聞く話です。お客様への説明責任は導入を支援するベンダー側にあると考えています。」と回答しました。
一方で、横井さんは、「AWSへの責任範囲と明確に記載されているのにも関わらず、AWSの責任範囲の範疇に対し、AWSに対して『詳細原因を調査しろ』と指示が出されているケースを目撃したことがある」といいます。
佐竹さんも「『ストレージの廃棄の方法を教えてくれ』も昔はありました。オンプレミスのイメージのままですね。こういった質問には地道に啓蒙活動をするしかありません。」とお話されました。
結論として、横井さんはこうコメントしていました。 「AWS側の責任範囲に問題が発生したときは、AWS側の対応を待ってください。AWSをお使いの方はこういったコミュニケーションにご苦労されている方は多いかもしれません。地道に勉強会をやっていくしかないのかなと思います。」
LT『AWSへのNIST SP800-171管理策導入に向けての整備』
LT Speaker
株式会社SHIFT ナショナルセキュリティ事業部 シニアコンサルタント 松尾 光敏
ChatGPTにNISTについて聞いてみました。
「NISTは米国政府の公式機関であり、標準化と技術ガイドラインの策定において長い歴史と高い信頼性を持っています。
NISTのガイドラインは、広範な研究と専門家の意見を基に作成されており、信頼性が高いと評価されています。」
セキュリティについての概念を集めて標準化をしている専門組織というイメージでしょうか。
世の中には情報があふれていますからね、独自にセキュリティ対応をしようとすると抜け漏れがでてしまいますよね。
こういった組織のおかげで世界の安全が守られているのですね！
NIST SP 800-171 Rev. 3は、2024年5月14日に最新版が出ています。
https://www.meti.go.jp/shingikai/mono_info_service/sangyo_cyber/wg_seido/pdf/004_06_05.pdf
LTでは、こちらのガイドラインをAWSサービスマップへ当てはめていました。ベースラインアプローチですね。
IPAの非機能要求グレード2018で考えると、非機能要件のセキュリティ―前提条件・制約条件 / 情報セキュリティに関するコンプライアンスに該当するようです。V字モデルでは超上流プロセスに該当します。
こちらがLTに登壇した松尾による解説記事です。
作成されたAWSサービスマップには、AWS環境へ侵入されたらレーザー(物理)で倒せ！！みたいなノウハウが詰まっているのでしょうか、、
ブラックハッカーにはひとたまりもないですね、、 （※想像です。SP800-171で標準化されているフレームワークには「報復」というフェーズはありません）
謎の多いナショナルセキュリティ事業部の一部が知れました。
下記はNIST SPシリーズです。
IPAでもいくつか翻訳したものが掲載されていました。
■セキュリティ関連NIST文書について
ここを読んでいるだけで1日をつぶせますね（^^）
参加した感想
今回のキーワードは、チームビルディング、ログの取得、避難訓練、根気強さ、教育だったかなと思います。
セキュリティというと、AWSの〇〇というサービスで対応できますという技術ばかりの内容になるかな、と予想していたのですが、 よい意味で期待を裏切られました。わたしはいますぐに避難訓練をしたいです。
長年AWSに関わってきた人達だからこそ語れる内容を聞けました。個人的にドキッとする言葉もあり、まだまだ勉強が必要だなと認識できました。
質問に対して、「どうしてそういう質問がでたのか」と背景を考えてから答えているのが印象的でした。
貴重なお時間をありがとうございました。
今後の大瀧の登壇予定
Jaws Festa
XSS攻撃から考察するAWS設定不備の恐怖（Lv400）
Track：C
10 / 12 sat. 11:35 ~ 11:55
今回の内容をさらに深堀した内容になっています！
執筆者プロフィール：kuro (実家で飼っている猫の名前です)
セキュリティサービス部
休日は、野良猫の保護活動に参加したり、たまにリアルボードゲーム会に参加したりしています。
昔はAndroidアプリを個人でリリースしたり、
ボードゲームのアプリをSocket通信で作り遊んでいました。
お財布にやさしいサーバーが好きです。
今までの職業は、プログラマー、アプリケーションエンジニア、クラウドエンジニアでした。
今はログの監視に携わっています。
お問合せはお気軽に
SHIFTについて（コーポレートサイト）
SHIFTのサービスについて（サービスサイト）
SHIFTの導入事例
お役立ち資料はこちら
SHIFTの採用情報はこちら