AWS環境でのセキュリティ対策について
はじめてnoteに投稿します。
ライフイズテックのサービス開発部 インフラ/SREグループに所属している「ぎだじゅん」と申します。
これまでこういった投稿はせずにインプットだけしてきたおじさんですが、ちょうど入社から1年経過して会社の命令で自分でも小さなことでもアウトプットしたほうがよいと思い、投稿します。
これまでの仕事
これまではSI営業からWEB制作に関する仕事へジョブチェンジ、WEB制作のディレクターから自社サーバの運用エンジニアへジョブチェンジしたのちに、ホスティングサービスのプリセールスを経て、約11年ほどWEBサービス系のサーバやインフラの設計/構築/運用を中心とした仕事を続けてきました。
最初はデータセンターのハウジングでのオンプレミス環境が中心でしたが、2015年くらいからAWS環境を中心とした設計/構築/運用をしています。
ライフイズテックでの仕事
前職で経験した新規プロダクトのインフラでのPCI DSS準拠のための環境設計/構築や、セキュリティ運用サイクルのルールや手順の策定や実施で得た経験をさらに深めたいと思い、現在の職場に2022年7月にジョインし、インフラ/SREグループの中で自社プロダクトのセキュリティ整備を中心とした仕事をしています。
入社してから1年間でやったこと
ライフイズテックに入社してからちょうど1年経過しました。
入社から行ってきたセキュリティに関する業務としては以下の4つがあります。
クラウド環境のセキュリティ態勢管理（Cloud Security Posture Management）の導入と運用
SIEM（Security Information and Event Management）の導入と運用
プロダクトのアプリケーションのセキュリティ対策
自社の情報システムのセキュリティ対策
今回はこの4つについて、簡単に紹介していきます。
1. クラウド環境のセキュリティ態勢管理（Cloud Security Posture Management）の導入と運用
ビジネスの変化のスピードを落とずサービスを提供していくうえで、インフラ基盤ではAWSなどのクラウドサービスの活用はなくてはならないものです。
会社によってはサービスやチームごとにAWS上に新しい環境を作成して検証したりリリースしたりすることが増えてきていると思いますが、知らないこころでリソースが増えていったり不要なリソースが残ったままの状態になることがあります。
また、それらのリソースがセキュリティの観点で問題のある設定になっていないか統制されていないと、場合によっては不正アクセスやクラウド上に保存されたデータの漏洩や破壊などが行われてしまう可能性があります。
AWSではこれらの問題に対して、リソースの変更状況などを収集してチェックを行い、問題のあるリソースを検出する以下のサービスがあります。
AWS環境のリソースの設定変更を記録するサービス
リソースの設定変更がセキュリティなどのルールに準拠しているかをチェックする（Security Hubでも利用されている）
AWSのリソースの設定状態をAWSのベストプラクティスや業界標準のベストプラクティス（CISベンチマークなど）に照らし合わせてチェックするサービス
今回、これらのサービスを使ってAWS上のリソースの追加や設定変更などの状態をチェックして、セキュリティインシデントを未然に防ぐように運用を行っています。
今回、Security Hubで以下のセキュリティ基準を使用してチェックを行っています。
現状では諸事情もあり自動修復などは利用しておりませんが、検出された未整備のリソースに対しては定期的にチェックをしてルールに該当するように修正対応を行っています。
プロダクトのサービス上、ルールどおりに適用することが難しい場合は、検出されたリソースの用途や稼働するサービス内容を踏まえてリスクを判断してルール無効化や抑制対応とするか別の方法をとるかなどを検討していきます。
無効化したルールなどはダッシュボード上で無効化した理由などを記載しておくこともできるため必要に応じて確認できますが、一部のリソースを例外として取り扱う場合は、なぜそのリソースを例外としているのかが記録できないので、抑制対応したリソースの理由などはNotionに記載して管理するようにしています。
また、SecurityHubのセキュリティ基準「CIS AWS Foundations Benchmark v1.2.0」での対策の中にありますが、IAMポリシーやセキュリティグループ、VPC関連の設定変更が行われたり、AWSのルートアカウントでのログインなどがあった場合は、CloudTrailのCloudWatch LogsからメトリクスフィルターとCloudWatch Alarmアラームで検出してSlack通知し、検出したリソースの変更状態をConfigで確認することで、不正な変更がないかを確認しています。
2. SIEM（Security Information and Event Management）の導入と運用
AWS上の各種ログを取得はしているものの、基本は保管だけしておき、何か問題が起きた時に確認することができるようにしている運用をされているところも多いかと思います。
問題が起きた時も原因特定などの分析をするには文字が羅列された情報では判別がとても難しいものになります。
取得したログからリアルタイムに分析することで、システムのセキュリティリスクの脅威を把握したり、インシデントの兆候を早いタイミングで検出することが可能になります。
これを実現するため、AWS上のセキュリティに関するログを一元管理し、それぞれの種類のログを横断的に分析できるようにログのフィールドを正規化して分析し、分析した内容を可視化できるようダッシュボードを提供するようなSIEM（Security Information and Event Management）の導入を行いました。
AWSではCloudWatchとダッシュボードを使って状況を可視化させるなどの機能はありますが、純粋なSIEMのマネージドサービスはありません。
かわりにAmazon OpenSearch Service を使って複数の種類のログを相関分析して可視化するソリューション「SIEM on Amazon OpenSearch Service」がGitHubで公開されています。
AWSのセキュリティに関する各種ログ（CloudTrail、GuardDuty、AWS WAF、Route 53 Resolver、VPC Flow Logs、ELBやCloudFrontなどのアクセスログなど）をS3バケットへ集めることで、自動でAmazon OpenSearch Serviceに取り込むようLambdaでETL処理します。
Amazon OpenSearch Service に取り込まれたログはOpenSearch Dashboardsにて可視化できます。
デフォルトでいくつかのダッシュボードが用意されているので、それを利用するか、デフォルトのダッシュボードで使われているパーツを使ってオリジナルのダッシュボードをカスタマイズ作成することも可能です。
ライフイズテックでは自社サービス環境に対しての接続状況やインシデントの兆候となりそうな通信の状況、各リソースの変更やAWS環境への不正なアクセスの兆候を確認できるダッシュボードを作成して、デイリーで状況を確認してNotionでレポート作成して関係各所への定期的な報告するなどの運用を行っています。
3. プロダクトのアプリケーションのセキュリティ対策
ライフイズテックでは開発を専門とするチームがおり、アプリケーションのセキュリティに関しては、脆弱性の検出などのチェックはインフラ/SRE、実際の対応や改修は主に開発のチームが行っています。
リリースにあたっては、アプリケーションに脆弱性がないかをチェックしたうえで行う必要がありますが、開発はスプリントで進められていることから、リリース前のテストなどのタイミングで脆弱性をチェックしたらリリースのスケジュールにも影響したり改修タスクが別途発生してくることでコスト増加してくることになります。
ついては、開発の初期工程のタイミングで対策ができるようにシフトレフトの取り組みを実施して現在の開発手法に合うようなセキュリティ対策を行っています。
開発前の段階からセキュリティに配慮したアプリケーションの設計やプログラミングが行えるように、初手の段階でコードの静的解析によるチェックや利用するOSSパッケージや依存関係のあるライブラリなどの既知の脆弱性などをコード管理リポジトリの開発用ブランチへプッシュするタイミングでチェックを自動で行うサービスの検証やトライアル導入を行いました。
今後、これを定期運用として開発チームと共に検出～対応サイクルをまわしていけるように整備していく予定です。
4. 自社の情報システムのセキュリティ対策
現在の所属はインフラ/SREグループで主に自社プロダクトのサービス基盤のセキュリティ対策を行っていましたが、会社内のセキュリティに関する統制についても課題としてあり、コーポレートチームと共に会社の情報システムのセキュリティ対策を行っています。
一例として、情報セキュリティを統制するためのルール作りや改善を行ったり、インシデント発生時に迅速に対応を行うためのインシデントフローの確立、従業員のセキュリティ意識の向上や会社の情報資産を守るために情報セキュリティ教育の教材を作成したり新入社員の入社時や全従業員へ定期的に実施を行いました。
最後に
これら以外にもIaaS環境においてAmazon Inspectorを使って脆弱性チェックと定期的なアップデートの運用を実施したり、GuardDutyによる脅威検出時の調査対応、既存のサービス基盤のセキュリティ的な課題に対しての見直しや設計、運用なども行ってきました。
入社して会社の環境の現状を実際に見て把握しながらで時間がかかってしまったこともあり、なるべく自分が行ったこれらの導入の考え方や運用設計、手順などは、会社のNotionにドキュメントとしてたくさん書くようにしていました。
そのため、個人別での月あたりのNotionの閲覧数や記述量などが毎月ダントツトップになってしまっており、今後はドキュメントを書くよりコードをもっと書いて解決できていけるようにしていきたいです。
また、導入はしたけど運用をまわしていくうえで課題なども出てきているので、引き続き運用をまわしながら改善していきたいです。
次回は、実際に行ったこれらの対応をひとつづつ少し深堀して解説したり、最近検証しているサービスなどのレビューやウェビナー/勉強会に参加したレポートなども（余力があれば）書いていけたらと思っています。
＜お知らせ＞
ライフイズテック サービス開発部では、今後定期的なカジュアルなイベントを実施しています。
開催予定イベントの詳細は ライフイズテックのconnpass からご確認ください。
興味のあるイベントがあったらぜひ参加登録をお願いいたします！
この記事が気に入ったらサポートをしてみませんか？