SREのusekです。気がつけばバレットグループにアサインしてから1年が過ぎ、今年もあと2ヶ月。今年は時間の流れが早く感じます。
リモートワークにも慣れましたが、先日久々に本社に出社してSREメンバーと対面でのミーティングやランチの時間を取ることができました。 こんな時勢ですが、こうやってチームの仲間と顔を合わせて話す機会も重要と思います。
私のミッションとしてバレットグループが提供しているサービス群を堅牢にするというものがあります。 特にバレットグループが自社サービスで多用しているAWSにおけるセキュリティ強化は重要です。 攻撃や障害によるサービスへの影響を防ぎ、発生した場合も素早く検知、対応するよう体制を整えなければなりません。
AWSには膨大なサービスがあり、使ったことはおろか聞いたこともないサービスも多々ありますが、セキュリティに関しても多くのサービス・機能が用意されています。
中には効果が重複しているものもあり、どのサービスを導入するかは時間対効果・費用対効果を検討するべきです。
組織の特性は組織の数だけあり、ある組織にとって有効な施策も別の組織にとってはそれほどでもない、というパターンも当然あります。
今回は私の作成したバレットグループ向けセキュリティガイドラインで定義されているAWS上のサービスを紹介します。 AWSのセキュリティ対応を検討されている方の参考になれば幸いです。
1. コストをチェックし、削減する
厳密にはセキュリティとは関係ないですが、「想定外のサービスが起動していて思わぬ請求が！」というのもインシデントと考えれば重要な要素です。
1-1. コストエクスプローラの有効化
厳密にコストを把握、分析が必要になることを想定して有効化します。 docs.aws.amazon.com
1-2. AWS Budgetsの有効化
思わぬリソースの作成・利用により多額の請求が・・・！ということを防ぐ方法はいくつかありますが、予算を設定して想定外の利用料金となった時点で通知されるようにすることで、被害を抑えることができます。 aws.amazon.com
ただ、どれくらいのコストに対してアラームを上げるのかをサービス稼動前に設定することは難しいです。 先日AWSが機械学習により、異常なコストを検出してくれる機能が追加されました。 こちらの導入も今後調査したいと思います。 aws.amazon.com
1-3. メンテナンスウィンドウ
開発環境や後述するAWS CLI用インスタンスなど、作業で使用している時以外はインスタンスを停止させることでコストを削減できます。 手動で行うと作業を忘れますし、もっと恐ろしいのは勘違いして別の本番環境を停止させるなんてことは避けたいです。
以下の記事は特定のインスタンスを再起動させる内容ですが、停止もほぼ同じやり方でできます。 業務時間外になったら開発に使用するインスタンスを停止させるよう、cron式を設定しました。
2. セキュリティ強化
2-1. ルートアカウント・IAMユーザのMFA設定
MFA（Multi Factor Authentication:多要素認証）は当然対応します。 特にルートアカウントは物理的なセキュリティキーを設定し、鍵は厳重に管理します。 物理キーの設定は以下の公式マニュアル通りにやれば簡単に対応できます。 docs.aws.amazon.com
作業者のIAMユーザにはスマートフォンにインストールする仮想MFAを使用しています。 弊社はAuthyをガイドラインで提示しています。当初コードをバックアップし、別のデバイスに移行する方法にGoogle Authenticatorが対応していなかったからですが、 最近Google Authenticatorもコードを別デバイスに移行できるアップデートがなされましたので、好きな方を使用してよいと思われます。
2-2. AWS CLI用EC2インスタンスの作成
IAMユーザのアクセスキーを有効化して、ローカルやインスタンス内で利用する方法を採用するとAWS CLIをすぐに利用できますが、アクセスキー漏えいによるセキュリティリスクがあります。 AWSの利用に関わるセキュリティインシデントも、アクセスキー関係が少なくありません。
booth.pm 上記「IAMマニア本」は評判が高くご存じな方もいらっしゃると思いますが、こちらの書籍の中で
そもそもアクセスキーは有効にしない
AWS CLIを使用したいのであればそれ用のEC2インスタンスを作成するべき
と紹介されていて、そちらを参考にしました。ぜひ読んでみてください。
2-3. AWS Configの有効化
AWS Configを有効化することで、AWS上のリソースの変更履歴を調べることができ、また変更前の設定に戻すことも可能になります。 設定変更を通知することもでき、予期せぬリソースの変更があった場合もすぐに対応可能です。 AWS Config Rulesという「セキュリティグループが全てのIPからのアクセスを許可している」「S3がパプリックアクセスされている」など特定のシチュエーションを検知する機能もあります。
2-4. Amazon Inspector
EC2にエージェントをインストールすることで、脆弱性のあるアプリケーションやミドルウェア、またインスタンスの設定にセキュリティリスクがないかをチェックしてくれます。 人間が手動でこの作業を行うと途方もない労力がかかるため、わずかなコストで診断をしてくれるこのサービスは非常に有用です。 ただし、脆弱性を修復してくれるところまではおこなってくれません。ここからがたいへんですよね😓
脆弱性情報にアンテナを張るべく、Slackのチャンネルに脆弱性関連のWebサイトのRSSや、セキュリティ情報をつぶやいているアカウントのツイートを集約しています。
2-5. SecurityHubの利用
もAWSアカウント状のリソースがセキュリティの標準ルールに従っているかを監査してくれるツールです。 「セキュリティグループが0.0.0.0/0からのアクセスを許可しているか」「使用されていないIAMユーザが放置されていないか」「S3がパブリックアクセスを許可していないか」など監査項目は多岐に亘ります。 もちろんこれら全てを満たすアカウントを運用することは現実的ではない部分もあるので、弊社では「このルールは採用」「このルールは不採用」などの基準を作成したうえで、監査結果が失敗した項目についてもきちんと説明ができるならばよし、と定めています。 リソースが更新される都度監査結果は更新されるので、定期的に棚卸すると良いと思います。
2-6. IAMアクセスアナライザーの有効化
IAMロールやS3バケットなどに、外部のアカウントや特定IPアドレスからのアクセス権が施されているリソースを検知するサービスです。 ボタンをクリックするだけで有効化でき、費用もかからないのでおすすめです。
3. 誤操作を防ぐ
インシデントは外部からもたらされるだけではありません。内部の作業者の誤操作を防ぐことはセキュリティ強化の重要な要素です。
3-1. アカウントのエイリアス(別名)の背定
AWSのアカウントのURLには12桁の数字(アカウントID)が含まれます。 複数のAWSアカウントを所有している場合、どのURLがどのアカウントなのか分からなくなりがちです。エイリアス(別名)を設定することで誤ったアカウントへログインすることを防ぐことができます。 後述のスイッチロールでも有効です。
3-2. マスターアカウントによるアカウント管理
最初は弊社も複数のAWSアカウントに対して、それぞれIAMユーザを作り、グループを作成して権限を・・・と作業をしていました。 あるサービスに対する権限を追加で設定したいという要望があれば全てのアカウントのポリシーを更新して・・・とやっているうちに限界になりました😅 アカウントごとMFAを設定するのもたいへんです。 マスターアカウント に各アカウントにログインするためのIAMユーザを作成し、スイッチロールで各アカウントにログインする運用とすることで管理コストが下がります。 方法は様々なページで紹介されていますが、簡単にまとめると以下になります。
サービスが稼働している個別のアカウントに、「管理者用」「エンジニア用」「閲覧者用」などのロールを作成し、用途に応じたポリシーを付与する
マスターアカウントで先のロールをAssumeRoleするポリシーを作成する
そのポリシーを持つグループを作成する
グループにIAMユーザを所属させる
マスターアカウントのIAMユーザからスイッチロールで、個別のアカウントにログイン
上記の手順を施せば1つのアカウントで各IAMユーザが個別アカウントにログインする権限を統制することができます。 完璧ではないかもしれませんが、コストもかからないので推奨できます。 スイッチロールの際、先ほど紹介したアカウントのエイリアスを使うとより安全にログインできます。
4. インシデントの早期発見・対応
問題が発生した場合、すぐに通知される仕組みが必要です。 弊社ではMackerel,CloudWatch,Zabbixを使用した冗長監視を行っています。また通知先もSlack,Teams,Gmailなど複数設定することでサービス自体の障害により通知が来なかった、ということがないようにしています。
4-1. AWS障害情報の把握
AWSで障害が発生した場合、以下のページに公式情報が掲載されています。RSSもあるので活用できます。 https://status.aws.amazon.com/
障害情報を呟くtwitterアカウントもあるので、これをフォローすることも有効です。
4-2. Systems Managerの有効化
インスタンスの状態をすぐに確認できる「マネージドインスタンス」や、インスタンスに接続できる「セッションマネージャ」。作業を自動化するための「ドキュメント」など、AWSの運用を担当する人であれば必ず有効化するべきサービスが揃っています。
4-2. Personal Health DashboardとSlackの連携
AWSアカウント上のリソースに影響する障害や、サービスのバージョンアップの通知など、対応が必要なイベントをお知らせしてくれる機能です。 通常AWSマネジメントコンソールにログインしないと見ることができないため、弊社ではChatbot（紛らわしい名前ですが、AWSのサービスです）を利用してSlackに通知しています。 こちらの記事を参考に簡単に設定できます。 engineer.crowdworks.jp
4-3. GuardDutyの利用
GuardDutyを有効化すると、機械学習を使ってアカウント内の怪しい操作や不審なアクセス検知、通知してくれます。重要度の高いシステムでは有効にしましょう。 設定自体は簡単ですが、リージョン毎有効にする必要があり煩わしいです。 クラスメソッドさんが一発で全リージョン有効化することができるCloudFormation StackSetsを用意してくださっていますが、それを利用しないにしても最低限東京リージョンは有効化したいです。
一点気をつける点として、GuardDutyはかなり細かく検知するため、通常のユーザ作業でもどんどんアラームをあげます。 アラームが膨大になると真に問題であるアクセスが見落とされてしまう危険性があるので、弊社ではseverityの値が一定以上のアラームのみ通知する方法を採用しています。 docs.aws.amazon.com
さいごに
いかがだったでしょうか。 今回紹介したものはAWS上のセキュリティ対策になるサービスの紹介です。 各サービス（EC2,RDS,S3など)にもセキュリティを向上させるための施策がガイドラインとしてまとめられています。
ここまで書いておきながら、バレットグループも上記の施策を全て対応しているわけではありません。
アカウントの用途、かけられる金額・時間などに応じてピックアップしています。あくまでガイドラインであり、絶対守るルールではありません。 ルールとすると硬直化し、サービスのリリースに必要な柔軟性やスピードに支障が出ることを懸念しています。
それでもAWSのサービスにはすぐ導入でき費用も軽微でありながらセキュリティを強化してくれるサービスがいくつもあります。 そして日に日に増えています。このガイドラインも常アップデートしていかなければと考えています。
