みなさん、こんにちは。ゴールデンウィーク前最後の日ですね。今日はお休みという方も多いのではないでしょうか。
ECS（Elastic Container Service）はコンテナ化を強力にサポートするためのサービスとして、日々アップデートが重ねられているAWSの主力サービスです。
古くから運用されているオンプレミスのサービスや、小規模なVPSでサービスを構築、運用している時にクラウド化を検討する機会は増えているかと思います。
そんな時に気になるのが「コンテナはどのようにセキュリティを確保し、仮想環境はどのようにログを保存し、日々の運用監視業務を行えるのか」という点。
今回はそんなECSの監視・運用に関わるキーワードとして代表的な「セキュリティ」、「IAM」、「ログ記録」、「モニタリング方法」に関して解説してみたいと思います。
セキュリティ
例えば大規模システムの受託を例にする場合、RFP（提案依頼書）の要求等から「システムの稼働するサーバーとアプリケーションはどのようにしてセキュリティを担保しているか」といった事項に関する確認があるかと思います。
AWSでは「責任共有モデル」という形でAWSを構成する要素に対してAWSが責任を持つ範囲と利用者が責任を持つ範囲を明確に定義して、AWS側の範囲に関しては「AWS Artifact」というサービスで包括的なレポートを入手することが可能です。
共有責任モデルについてざっくり言うと「AWS側で面倒を見れる所はちゃんとやるので、ユーザーが設計できる範囲に関してはユーザー側で責任を取ってね」という事になるので、例え抽象化されたECSのようなコンテナ環境であっても、責任共有モデルが意味する「利用者が担保するべき責任」に対してその範囲を適切に理解して、それらに対してベストとなる対策を実施することがECSの構築・運用において重要となってきます。
参考：責任共有モデル | AWS
https://aws.amazon.com/jp/compliance/shared-responsibility-model/
IAM
まず、コンテナから開かれたミドルウェアやアプリケーションのポートに対するアクセス権限はVPC／セキュリティグループ等によって適切に管理されていなければいけませんが、これはアプリケーションの実装によるものなので割愛します。
AWSのコンソールやAPIを介して「ECSや、それによって管理されたコンテナを操作する」行為に対しては、全てIAM（Identity and Access Management）によって制御されます。
まず、IAMを適切に管理・運用するためには権限のスコープによって3つに分類でき、それぞれ次の通りとなります。
- サービスユーザー
ECSへのデプロイの定義・実行やコンテナへのログイン等を行う、開発／運用担当者やCI/CD・コンテナ上で動くアプリケーション等に対して業務用途に絞って最低限の権限が与えられる
- サービス管理者
ECSに関するシステムの「運用責任者」が持つ権限に相当し、ECSのフルアクセス権限と、サービスユーザーがどんな権限を必要としているかの管理や棚卸しを行う
- IAM管理者
サービスユーザー（従業員やJenkins等のツール）の出入りや実行権限の変更に対して、適切にIAMを管理・運用してゆく
IAMによる権限の管理を雑に行う（全員Administratorにしてしまう等）事を行うのは非常に簡単で、「本当に問題になるまで問題にならない」事が厄介ではあるのですが、オペレーションのミス一つでビジネスにダメージを与えかねない重要なポイントでもあり、構築の初期からIAMに関してしっかりと管理・運用してゆく計画が必要です。
「雑に管理していたらいろんなアプリに野良のIAMが混ざり、そのIAMに関する認証情報はパスワードなので暗号化されてデプロイされており、どのサービスがどのIAMを利用しているか分からなくなってしまった」なんて事にも最悪なりうるので、痛い目を見る前にしっかりとIAMを管理・運用してゆくための準備をしておきましょう。
ログ記録
アプリケーションの状態やインフラを監視するソリューション（Zabbix等）は古くからあり、また、細かい要件の次第によってはそれらを検討する必要も生じますが、基本的にAWSの責任共有モデルにおけるユーザー側の責任となる箇所のログ記録に関しては、AWSのサービスとしてそれぞれ提供されています。
- Amazon CloudWatch アラーム
ECSのコンテナのヘルスチェックからリクエストの監視まで、標準で一通り揃ったメトリクスに対してアラームを設定し、傾向監視から閾値ベースの異常検知まで設定が可能
- Amazon CloudWatch Logs
コンテナ上で稼働するアプリケーションのログをリアルタイムでストリーミングして、それらのログをCloudWatch LogsのWeb管理画面から細かい粒度で検索・表示する
- Amazon CloudWatch Events
CloudWatch アラーム／CloudWatch Logs／CloudTrailそれぞれのメトリクス／ログから異常検知やログに含まれるキーワードをトリガーとして、メール通知やLambda Functions等によって検知に対する初期対応を行う
- AWS CloudTrail ログ
IAMを含めECSに対して「いつ・誰が・何を」したか記録し、サービスやコンテナに対してどのような変更が加えられたかを記録する
- AWS Trusted Advisor
有人サポートの窓口として、AWSの利用に関してメールサポートから対面のレビューまで提供しており、もちろんセキュリティに関するサポートも受ける事が可能
ざっくり上記のような役割を持って、相互に機能しながらECSを取り巻くログを監視することが可能となります。
基本的なログ監視基盤から発展してAWS Kinesis等のデータ処理パイプラインを利用して異常検知しつつS3にログを送り、Athenaから分析……といったログ収集基盤も構築することも可能です。
マイクロサービス化された大規模システムのログの量は尋常ではなく、CloudWatch Logsによる利用料金が凄い事になってしまうケースも多々あります。 そんな時には別途ログ収集基盤の構築を検討するとコストや利便性の点からメリットが出るケースもあります。
いかがでしたでしょうか。今日は 「セキュリティ」、「IAM」、「ログ記録」のキーワードを元に、お伝えしました。明日は続きの「モニタリング方法」についてです。
▼「無料相談」受付中です。AWSに関することは、どんなことでもお気軽にご相談ください。
https://www.sunnycloud.jp/contact-us/
AWSをご利用いただくには、直接契約するより断然お得。
AWS利用料が5％割引、さらに日本円の請求書による支払いが可能です！
