※SHIFT EVOLVEとは？
SHIFTグループが主催する技術イベント。 エンジニアコミュニティから技術をEVOLVEしていこう、という想いで運営し、メンバー登録者数は3,300人を超える（2024年10月時点）。開催予定のイベントは以下よりチェック。
https://shiftevolve.connpass.com/

テーマ①AWSの各種セキュリティサービスを入れてはみたものの、ちゃんとできているか心配。数年運用してみてどうだった？

横井：こういうご質問が出るということは、たぶん導入するときはちゃんと議論して網羅的にできていた。

設定した当初はグリーンランプを確認していたものの、そこから1年、2年、3年とおそらくは放置していた、ということなんでしょう。

やはり中間地点でチェックする仕組みですとか、日ごろからセキュリティに関して議論をするとか、定期的に見直していく運用の有無にすべてかかっているんだろうなと思います。

この辺りは仕組みと人の力の両面で守っていく必要があり、特に後者について、1週間に1回はダッシュボードを見て会話をするような状況を会社のなかでつくっていくべきなのかなと思います。

王道のように聞こえるかもしれませんが、これができていない企業さんが実は多いと思っています。

佐竹：セキュリティコントロールと呼ばれる一つ一つって粒度がすごく小さくて具体的ですよね。その上にその会社のスタンダードがあり、さらにその上に組織としてやるべきセキュリティ対策があるはず。

そういう3段階ぐらいの構成があるなかで、各企業におけるセキュリティの目的が果たされているか？はそのためのセキュリティチェックになっているかは確認すべきでしょうね。

ベストプラクティスだけやってる、は危ない気がします。

大瀧：よくあるのが、Inspectorの検出結果をほぼ無視する問題とかですね。なんでそんなことが起きるかっていうと、やはりインフラとアプリってチームが違うからなんですよね。

Inspectorで脆弱性が検出されるからインフラ側は脆弱性を意識できるのですが、例えばOSSってどちらかというとアプリ寄りで、インフラチームから指摘はしたものの、直されずに放置されるものが山のようにある。

それをどうしていくのかという話は、永遠のテーマというか、解決できないテーマとしてあるわけです。

横井：古くからのIT企業さんだと、インフラ部門とアプリ部門はわかれています。

インフラをつくったらそれを引き継いで「じゃあアプリのみなさま、よろしくお願いします」みたいな感じで開発している会社だと、やっぱりモダンテクノロジーになったときに、その歪さが出てくるんだと思います。

なので責任範囲を前向きに見直していくとか、そういう基本的なことが大事かなと思います。

佐竹：そうですね。だいぶ前にDevSecOpsの概念も話題になりましたけど、インフラもアプリ部門が見る、領域や部署の垣根がなくなるというような流れが当時あったじゃないですか？

実際、最近クラウドもやれるようになってからインフラエンジニアの価値が見直されているようにも思いますね。

テーマ②：AWSのセキュリティサービスだけで万全？外部ベンダーで補う方がいいことってある？

大瀧： 最近、GuardDutyが何だかすごく一押しみたいで「それだけ入れればいいんじゃない？」と考える方もいらっしゃいますよね。

佐竹：GuardDutyはセキュリティリスクが発生した後に検出するもので、事前対策という観点では不十分だと思います。ボヤが起きてから煙が立っているのを見つける、みたいな状態です（笑）。

横井：事前に対策するには、やっぱりセキュリティに関するチェック項目みたいなものをちゃんと押さえておく必要があると思います。必要最低限のところで例をあげると、レッドランプを残さない、とかですね。

でも、毎日人が見てチェックするわけにもいかないので、実際に動いている環境のところにエージェント型セキュリティソフトウェアを使い、そこで逐一、怪しい振る舞いが起きていないか、ルールに反する何かが置かれていないかなどを見て、自動的にその環境が汚染されていないかどうかを監視することで、AWSではカバーできない範囲を補うことができます。

大瀧：ただ最近、 GuardDuty EC2 Runtime Monitoring が出てきたじゃないですか。じゃあそれって、某有名なエンドポイントセキュリティの製品と比べてどうなのかみたいな話がありません？

佐竹：この辺りって、たぶんEC2の話なんですよね。責任共有モデルでは、EC2の中身はエンドユーザーの責任になっているから、そこでやらざるを得ないってことだと思うんですけど。

大瀧：逆にLambdaにすればすべて完璧なんですかね。OSSの問題は残ると思いますが。

佐竹：Lambdaにも実は「ちゃんとスキャンをする」っていうInspectorの項目があるぐらいですが、完璧ではないにせよEC2を立てるよりかは圧倒的に攻撃される可能性は低いですよね。

責任共有モデルでエンドユーザーの部分が大きいサービスを使えば使うほど万全ではなくなっていくし、RDSってそもそもエージェントを入れられないじゃないですか。

だからそういうのを使っていけばいくほど、これで十分足り得ることになっていくので、まずはその部分じゃないですかね。

横井：普遍にできるけどセレクトはできるんですよね。そのなかでリスクを極限まで下げるには最小権限っていう選択になるかなと。

がばがばになったままリリースしちゃわないよう、どこを守るべきで、どのアクセス権限に絞らないといけないかは基本に立ち戻って確認しないといけない。

大瀧：あとは、リソースに優先順位というか、重みづけをする感じですかね。ここ大事ですよね。

横井：明快に定義してやれている会社さんって実は少ないんじゃないかなと思います。

要は暗黙知になっていて、会社のなかで「これは重要なシステムだから」っていうことで判断して、そこだけ重厚な対策にしているというのはあると思います。

佐竹：例えば障害が発生して復旧までに何十日もかかるみたいな場合。どれから復旧させるか優先順位がつけられない、だと困りますよね。

暗黙知ベースでお客様に聞くと「全部復旧してくれ」っていわれるだろうけど「やるけど、どれからやります？」って。 

横井：トリアージみたいに整理しておくのがいいんでしょうね。

佐竹：データとかリソースについても、タグをつけとけばいいですよ。タグが多分一番楽ですし。

テーマ③：いざ不正アクセスされて、情報漏洩が発生したら、何から手をつければいい？日ごろから準備できることは？

大瀧：僕らだとまず、有事の際にちゃんとログが追えるようにしておきましょうということで、経路別に全部ログは残してもらうようにしています。

情報漏洩が発生したらちゃんとその影響範囲が特定できるようにしていくというのが最初のおすすめポイントかと思います。

佐竹：いきなり話がちょっと外れるんですけど、CloudTrailのログをずっととっておくというのは基本中の基本になります。

CloudTrailのログ記録機能はオプション機能ではあるものの、デフォルトで有効化されていて90日くらい見ることができるんですよね。

CLI越しで操作したらAPIのログがほとんど残るので、こういうところをちゃんと理解できているかって、実はけっこう大事かなと思います。

ただ、データベースのなかの情報を抜かれた場合は、データベース側の監査ログなどがないとわからないので、やはり本番環境やセンシティブな情報が入っている環境は全部監査ログをオンにしておく、例えばCloudWatchを流しておくなどしておかないと怖いですね。

横井：あとは、ログをとって安心しないことも大事だと思っています。特にトラブル対応やセキュリティインシデントのときに、マニュアルやエスカレーションフローというのが非常に重要になってきます。

結局、最後は人が動くわけですから、事前に準備しておかないといけないと思います。

一つイメージしやすい例でお伝えすると、地震が起こったときに公共放送では対応内容がすべてあらかじめ細かく決まっています。

ちゃんとマニュアル化されているしフロー化もされているから、何かが起こっても慌てずにできるというわけです。

しかもそれは日ごろから訓練をして、ちゃんと従業員教育しているから、誰がやっても大丈夫ってなっているわけです。

まさにIT運用でも活かせるなって思うときがあり、AWSのWell-Architected Frameworkももちろん大事なのですが、つね日ごろから行われているITじゃないところの防災対策とかも大事で、それを怠らないことで迅速な初動対応ができるようになるのではないかなと思います。

※本記事の内容および取材対象者の所属は、イベント開催当時のものです