これまでの連載はご覧になっていただけましたか？
まだの方は以下の連載も合わせてよろしくお願いします。
今回は連載第7話になります。今回の話題はセキュリティ(全2回のうち第1回)です。
なお、ストーリーはフィクションであり、実在の人物・団体とは一切関係ありません。
7話 管理
この日、A君は日が昇る前に起きた。
ヨーロッパのサッカー各国代表が頂点を争う4年に1度の祭典、EURO2016をテレビで観戦するためだ。
A君は、この大会のためにわざわざ衛星放送を契約していた。
今日は特に楽しみにしていたベルギーvsイタリアだ。
キックオフまで少し時間があるからAWSの勉強をしよう。A君は試験要覧を開いた。
「次はセキュリティか。」
ドメイン 6.0: セキュリティ
6.1 情報セキュリティマネージメントシステムとコンプライアンス統制を設計する
6.2 AWS 責任分担モデルおよびグローバルインフラストラクチャによりセキュリティコントロールを設計する
6.3 ID およびアクセスマネージメントコントロールを設計する
6.4 保管中データのコントロール保護を設計する
6.5 伝送中データおよびネットワーク境界のコントロール保護を設計する
「上から見ていこう。ええと・・・まずは『6.1 情報セキュリティマネージメントシステムとコンプライアンス統制を設計する』かぁ。」
「情報セキュリティマネージメント、となると関連してるのはCloudTrail, CloudWatch, Configあたりかな。セキュリティを自動で評価するInspectorなんてのもあるのか。
セキュリティやコンプライアンスの検証や改善を支援するサービスがいろいろあるんだなー。」
「CloudTrailは、いつ誰がどのAWS APIを叩いたかを記録し、S3にログファイルを送信するサービスか。
ログファイルが送信されるたびに通知を送ったり、ログファイルが変更されたかどうかを検証したりもできるのか。」
「CloudWatchは、EC2をはじめとするAWSのリソースをモニタリングするサービスなのか。
CPU使用率などをメトリクスとして収集したり、メトリクスにアラームを設定して通知したりできるのか。S3に蓄積されたログファイルについて、モニタリングやトラブルシューティングを実行したりもできるんだな。なるほどなー。」
「Configは、AWSリソースの現在の設定内容の情報を提供したり、それらのリソースの設定変更が継続的に記録したりするサービスか。
Config Rulesってのを使うと記録された設定を自動的にチェックするルールを作成できるのか。へぇー。」
「Inspectorは、AWSを使用しているアプリケーションのデプロイ前や運用中に、アプリケーションのセキュリティ規格やベストプラクティスを遵守しているかを自動で評価するサービスなのか。
セキュリティ規格やベストプラクティスといったルールがセキュリティの研究者によって都度更新されるのは、利用者側も安心できていいなぁ。」
気づいたらサッカーの試合そっちのけで勉強していた。
テレビに目を向けたら試合はもう終了間際で、ベルギー有利と目されていた中でイタリアが2点目を決めていた。
「そろそろ仕事に行く時間だ。仕度をしよう。」
出社したらフロアの様子がいつもと違う。なんだか隣の部署が騒がしい。
何が起きたのだろうと不思議に思いながら見つめていたら、O上司が席にやってきた。
「昨日からシステムの一部の機能が利用できなくなっているとお客さんから問い合わせがあって、解析しているところなんだ。少し前にデータベースの容量が問題になっていたあのシステムだから、AWSを勉強してるAも力を貸してくれないだろうか。」
A君は隣の部署を訪ねた。システムのメンバー達が険しい表情でPCと向き合っている。
「ログはどこで取ってるんですか？」
A君はシステムのメンバーの一人に尋ねた。
「システムを構成しているEC2のログをfluentdで集約してS3に溜めているのですが、膨大な量のログから原因をつきとめるのは時間がかかります。」
「設定どうなってますか？・・・うーん、これでは解析に時間がかかりそうですねー。」
「あっ！！」
システムのメンバーの一人が声を上げた。システムを構成するS3が1つ削除されていたようだった。
「誰かの誤操作かなぁ。まぁいいや、一件落着。すぐにお客さんの問い合わせに対応しよう！」
「分かりました！」
メンバー達のやり取りを見届けながら、A君は明け方勉強したことを思い出していた。
「AWSを使っているなら、CloudTrailの導入を検討してみてはいかがでしょうか。」
A君はCloudTrailでどのようなログが送信されるか、などといったことを説明した。さらにA君は続けた。
「CloudTrailにより蓄積されたログを、CloudWatchでモニタリングして異常があったら通知を送るようにすると、ログ解析の時間がかなり短縮されると思います。CloudWatchはログだけでなく、CPU使用率やメモリ使用量などのモニタリングもできますよ。」
「なるほど、それならすぐにでも導入を検討したいですね。B部長に相談してみます。ありがとうございます！」
席に戻るとS先輩が話しかけてきた。どうやら会話を聞いていたようだ。
「ちゃんと勉強するだけでなく、現場での問題解決に貢献しているのね。いいね。」
「ありがとうございます！」
「あら、鼻の下が伸びているように見えるけど気のせいかしら。そして、惜しい。」
「え・・・？」
「AWSアカウントを持つ人が、ストレージを簡単に消去できてしまうことに対しても何か改善できるかもよ。」
S先輩のその言葉が引っかかり、その日の夜は該当しそうなAWSのサービスを勉強していた。深夜1時に。
おもむろに試験要覧を見てみると、勉強している内容が『6.3 ID およびアクセスマネージメントコントロールを設計する』にあたるものだと気づいた。
同時に、ハンガリーの本大会44年ぶりの勝利を見届けた。
翌日、再び隣の部署を訪ねた。
「昨日の件なのですが、システムの監視や異常検知の他に、
Identity and Access Management(IAM)を利用してアカウントごとにアクセスやリソースの操作を制御するのはいかがでしょうか？どのユーザーが、どのAWSリソースに対して、どのような操作ができるかを詳細に制御することができます。
また、昨日お話ししたCloudTrailを使用していると、ログにリソースにアクセスしたユーザーに関する情報が保存されます。」
リソースだけでなくアプリケーションへのアクセス制御もできること、IDフェデレーション(認証連携)に対応していることを話した。
システムのメンバーの反応は上々だ。
「アクセスの制御が詳細にできる上に、誤操作のリスクもいくらか軽減できそうですね。IAM単独では使用料が無料のようなので試してみます。」
後日、隣の部署のB部長がお礼に来てくれた。
「A君ありがとう。君が提案してくれたサービスの導入が終わったよ。
そういえば、Oから再来週のミーティングの話を聞いたよ。ミーティングで顔を合わせる前にこんなトラブルに巻き込んでしまって申し訳ないけど、うちのメンバーをよろしく頼む。」
「はい、こちらこそよろしくお願いいたします！」
隣の部署から頼りにされているのがひしひしと伝わってきた。この積み重ねから、強固な信頼関係が生まれるのだろう。
席に戻ると、普段はクールなS先輩がこちらに向かって微笑みかけていた。
「A君、隣の部署に頼りにされてるわね。やるじゃない。」
「ありがとうございます！」
「でも、その笑顔は少し不気味ね。」
「え・・・」
S先輩の笑顔を真っ向から拝めた嬉しさから、必要以上に口角が上がっていた。
「あと、もしかして最近不規則な生活をしてる？肌が荒れてきてるわよ。」
ばれていた。今晩はサッカーなんて見ないでゆっくり休もう。
次回は引き続き「セキュリティ」をテーマにする予定です。よろしくお願いします。