情報システム部でAWS周りの運用保守をしている「ねぎ」です、こんにちは！
先日AWSさんの定期開催イベントである、ちょっぴりDiveDeepに登壇しました。
今回は登壇内容についてブログで紹介したいと思います。
ちょっぴりDiveDeepとは
正式名は「アップデート紹介とちょっぴり DiveDeep する AWS の時間」というオンラインセミナーになります。
AWS の数あるアップデートの中から「すぐ使える、運用に役立つ、あったらいいなと思ってた、おもしろい、重要」なものをピックアップして紹介してもらえるのと、何名かの方がその会のテーマに沿って発表するセッションがある、といったイベントになっています。
今回のテーマは「Security」でした。
2023年9月回は特別回「AWS re:Inforce デモ祭り」が開催されます。（9月6日開催済み）
通常会も予定されていますので、少しでも興味がある方は登録をオススメします。
発表タイトル
AWS 初心者が取り組んだセキュリティ強化の 2 年間とこれから
というタイトルで登壇をさせてもらいました。
私は弥生に入社するまでクラウドの業務経験がない経歴で、2021年8月ごろから本格的にAWSを業務で使うようになりました。
その時に開発チームが使いやすいAWS環境をゼロから構築せよ、という仕事をすることになったので、
今回2021年8月ごろから取り組んできた「Security」のテーマに合わせてその内容を発表しました。
こんな感じで当日は発表していましたｗ
以降は当日実際に発表した内容についてブログでも紹介します。
弥生にまつわる数字
本編に入る前に弥生のAWS状況を紹介します。
弊社では過去にこのような経緯があって、Securityをより意識するようになったという紹介となります。
まず１つ目は
この２年間で２件から、直近の１年間は０件になっているという数字です。
この数字が何なのか
が答えでした。
Securityに関する対策をきちんとやらないと、外部からの攻撃をすぐ受けてしまうという、苦い過去の教訓でした。
続いて２つ目です。
こちらは年々数字が増えている状況です。
この数字が何なのか
AWSアカウント数でした。
右肩上がりで増えている状況となっていて、今後は300～500アカウント（※）の数になることを見越して、Security対策をやらねばと日々考えて続けています。
※2021年5月に100アカウント規模の運用を見据えた、もくテク発表時の資料を公開しています。こちらも良ければ見て頂ければと思います。
以上２点、弥生のAWS環境の状況を紹介しました。
以降が発表の本編となります。
弥生で取り組んでいるSecurity施策
「弥生にまつわる数字」でご紹介した通り、1つ目でSecurityの対策を早急になんとかしなければ、となりました。
そこで弊社では「AWS Security Hubの検知・自動修復対応」のソリューションを活用することにしました。
また２つ目でAWSアカウント数が右肩上がりで増加している状況から、Security検知があった時に複数のアカウント横断で調査出来るような仕組みを整えていく必要があると考えました。
その点を解決するために弊社では「SIEM on Amazon OpenSearch Service」のソリューションを活用しております。
当日の発表ではこの２点について弊社の活用事例を紹介しました。
AWS Security Hubの検知・自動修復対応
AWS Security Hubの検知・自動修復対応の話をする前に、AWSを活用されている皆様、AWSの主要なSecurityに関する通知をどのようにキャッチアップしているでしょうか？
登壇時にもまずはどのように検知をしているか、のお話をさせていただきました。
弊社の検知の仕組みの変遷については、以下のブログで詳細にお話していますので、あわせてご覧いただければ幸いです。
このように検知の仕組みを整備しつつ、特にこの設定されていると「弥生にまつわる数字」でご紹介した１つ目のような状況になってしまう可能性があるものは、自動修復（強制的に設定を削除、もしくは設定を変更）するような仕組みを整備してきました。
「AWS Security Hubの検知・自動修復対応」ソリューションのアーキテクチャ（弊社向けに一部修正）となります。
こちらの仕組みを導入後、AWS Security Hubの各違反IDの影響調査と弥生のポリシーとして違反を是正するかどうかの判断、是正する場合は自動修復させるのか、検知までにするか、を決めて対応を進めています。
このように２年間で検知と自動修復ルールの件数が増えており、成果として「弥生にまつわる数字」でご紹介した１つ目の検知件数が直近１年間はゼロ件となっています。
ここまでお話したことをまとめると
- 検知の仕組みを整備 → 各チームで検知の確認・対応が出来るような基盤整備と啓蒙活動
- 「AWS Security Hubの検知・自動修復対応」ソリューションの活用 → 本当に危ない設定は強制的に削除・設定変更
弊社で取り組んだことは上記の２点となります。
この２点に取り組んだことで
このような良い成果が出てきました。
当初は検知の仕組みを整備して、各チームへ直接検知内容を通知をした場合、主体的に対応をしてもらえるだろうか、という心配がありました。
しかし、実際にやってみると各チームのSecurity意識が高まると同時に、AWS Security Hubのスコアも上昇していくという想像以上の成果が出る結果となりました。
AWSのSecurityで同じような悩みがある方は、是非参考にしてみてもらえたらと思います。
SIEM環境の構築
AWSアカウント数が増えていくにつれ、エラーが発生した根本原因を追うのが難しくなっている、そういった悩みはないでしょうか？
弊社ではそういった悩みに対応するため、ログを集約して分析出来る「SIEM on Amazon OpenSearch Service」のソリューションを活用しております。
上記がアーキテクチャとなります。
AWS Security Hubの違反が検知されたときに、「誰が」、「いつ」、「何をやったか」をOpenSearchにてCloudTrailログやその他のログを合わせて相関分析で調査することが多くありました。
一方OpenSearchですが分析対象のログが増える（種類や容量）につれて、Indexのローテーション、ディスクの管理、ノード管理、バージョンアップなど運用工数が増えていくことに悩んでいる方もいたのではないでしょうか？
そこで弊社では、積極的に以下２つの新しいサービスの活用をしていきたいと思っています。
「Amazon OpenSearch Serverless」と「Amazon Security Lake」です。
「Amazon OpenSearch Serverless」の活用で、運用工数の負荷軽減を狙い、「Amazon Security Lake」でオンプレミス環境のログも含めて集約、OpenSearchにしばられない分析方法の採用も視野に運用出来るよう、アーキテクチャを変更していこうと考えています。
こちらがこれから構築していこうと考えているアーキテクチャイメージとなります。
AWSのログをどこまで取得、分析するのか、他のツールとの役割分担はどうすのか、など技術的要素以外の整備も必要になり、時間がかかりそうですが、何かあった時の調査スピードを上げられるよう、整備を進めていきたいと思っています。
発表資料は以下です。ぜひご覧ください。 speakerdeck.com
まとめ
今回の登壇では、弊社のAWS Securityに対する取り組みの内容をお話させていただきました。
AWS Security Hubの違反ルールに対するアップデートであったり、「Security」に関するアップデートがAWSはとても速い印象があります。
弊社では引き続きAWSの新しい技術を活用しながら、全社的な基盤を整備しながら開発チームと連携して、「Security」の向上に努めていきます。
弊社のAWS環境の技術的な支援をしていただいていた、AWS桂井さんからのコメントをいただきましたので、掲載させていただきます。
AWS桂井さんからのコメント
ご登壇いただきありがとうございました。
セミナー参加者にとって学びになる内容だったことに加え、弥生様がSecurity強化に対して真剣に取り組んでいることが伝わる内容だったと感じております。
AWS Security Hub をご利用いただいていますが、サービス利用だけでなく修復対応の自動化にも取り組まれたことが重要だと考えています。
アカウントの数が増えて運用負荷が高まる可能性もあった中で、各チームと連携して対応を進めて全員でSecurity対策に取り組み、効果も出ていて素晴らしいです。
この施策をサポートできたこと、結果としてSecurity強化が実現されていること、非常に嬉しく思っております。
改めてありがとうございました。
あとがき
いかがでしたでしょうか？
どのようなインフラ基盤でも避けて通れない「Security」、今回のちょっぴりDiveDeepのテーマは「Security」で、他の発表セッションもとてもタメになるものが多かったです。
普段何事も無ければあまり表に出ない部分になるかと思いますが、日ごろから意識して整備してなければ、「いざ」という時に使えないものになってしまうかと思います。
引き続き弥生では、開発チームの意見も聞きながら、みんなで活用してもらえる基盤整備に引き続き取り組んでいきます。
ちなみに、、、
当日は発表セッションのトップバッターだったので、すごく緊張をしていました。
逆にトップバッターだったので、発表が終わった後はその他のセッションを落ち着いて聞くことが出来ましたｗ
次回登壇する際にはAWSサービスをさらに活用した弥生の姿を発表出来るようにしたいと思います。
