AWSアソシエイト試験に向けて14(AWSのセキュリティと運用の話）

はじめに

Well-Architected Frameworkでは安全性の部分。
ベストプラクティスではセキュリティの確保の部分。
運用自体はまあ全般的な話。

責任共有モデル

AWSではユーザー側とAWS側でセキュリティに対して責任を分担して追うような形式になっている。
ユーザー側では

• 自らが設計したAWSインフラストラクチャ
• ユーザーアクセス
• ロールベースのアクセス(ロールを付与したり作成したりすることを含む)
• ユーザーが利用するAWSサービス

これらに対してセキュリティ対策を行う責任がある。
特に

• IAMによるアカウント管理
• セキュリティグループの設定
• アプリケーションロールベースのアクセス設定
• ネットワーク・インスタンスオペレーションシステム(バッチ)などの設定を行う
• OS/ホストベースのファイアウォールを設置する

このあたりは確実に行う。
対してAWS側は

• AWSインフラストラクチャを提供するためのハードウェア・ソフトウェア・ネットワーク
• AWSデータセンター

これらに対して責任を負う。
この前提を頭に入れておく。

AWSにおけるセキュリティの設計について

AWS内のデータ・システム・アセットを保護して、モニタリングによってセキュリティを高めていくという設計思想。
以下のようなことを守って欲しいらしい。

• すべてのレイヤーでセキュリティを適用する
• アクセス追跡・モニタリングを確実に行う
• 条件ドリブンのアラートをトリガーとしてセキュリティイベントへの応答を自動化する
• 責任共有モデルに基づいて、セキュリティ保護を行う
• セキュリティのベストプラクティスを自動化する

セキュリティのベストプラクティスは以下の3点。

• ソフトウェアベースのセキュリティ設定を使用し、迅速かつコスト効率の良いスケーリングを安全に実行
• 仮想サーバーのカスタムベースラインイメージによる新サーバーへの適用を自動化
• インフラストラクチャ全体のテンプレ化による管理

セキュリティの主要サービス

以下4つの観点でサービスが分かれる。

データ保護

• ELB
• EBS
• S3
• RDS
• KMS

つまり、ストレージの暗号化ということになる。
例えばより厳しい暗号化要件に対応するために暗号キーの暗号化をするためのサービスとしてCloudHSMがあったりする。

おさらい(S3の暗号化)

• サーバーサイド暗号化……AWSサーバーリソースを利用して格納しているデータの暗号化を行う

• SSE-S3、SSE-KMS、SSE-Cが該当する

• クライアントサイド暗号化(CSE)……ユーザー側で管理する暗号化タイプ

• カスタマーキーをKMSで暗号化するか、クライアントのマスターキーで暗号化するかする

RDSの場合

以下の3点からデータ保護を行う。

• セキュリティグループ(DB・VPC・EC2それぞれのインスタンスへのアクセス制御を適切に行う)
• データ接続の暗号化……SSL/TLSプロトコルでアプリケーションとDB程度インスタンス間のデータ接続を暗号化する
• リソースの暗号化……暗号化オプションにより保管データを暗号化する

KMS

AWS提供のマネージドな暗号化サービス。
暗号鍵の作成・管理・運用を実施するマネージドサービスであり、コンソール・SDK・CLIなどを利用してキーを作成し、管理できる。

• IAMと連携して鍵のアクセス管理ができる
• CMK(カスタマーマスターキー)の無効化・有効化・削除を実施することで、1年毎に自動キーローテーションが可能
• CMKは外部から持ち込んだものも管理できる
• キーを保護するためにFIPS140-2の検証済みまたは検証段階のハードウェアセキュリティモジュールを使用する
• CloudTrailと統合されていて、すべてのキーの使用ログを表示できる
• RDS・S3などの多数のAWSサービスに適用できる
• SDKを利用するとアプリケーションにおける暗号化も可能である

カスタマーキーとは

• 暗号化を実行する上で、最初に作成されるマスターキー
• 暗号化キーを暗号化する
• ローテーションされる

という性質のキー。
カスタマーデータキー(暗号キー)は

• 実際のデータの暗号化に利用するキー
• KMSで生成されてCMKで暗号化される

という性質のキー。
で、これら2つのキーを利用してマスターキーではなく、実際のデータにはカスタマーデータキーで暗号化を行いマスターキーは暗号キーの暗号化を行うような二重の暗号化体制を取るような暗号化方式をエンベロープ暗号化と呼ぶ。

権限管理

• IAM
• MFA

まあ言わずもがな。
責任共有モデルの考え方もこちらの領分になる。

AWS Directory Service

ユーザーに関わる各種情報を保管してユーザー認証を実現する仕組み。
オンプレにおけるActive Directoryという仕組みに代わって使うらしい。
IAMと連携させて使う……というかIAMと似たような役割であり、要はユーザー情報をディレクトリを用いて管理してどのユーザーがどれだけ情報を持っていて、どういう権限が与えられているかをわかりやすくするもの。
で、管理されたユーザー情報を使ってIDとアクセス管理を行ったりファイル共有やバッチ処理などのアプリに対してのアクセス制御を行う。
利用方法としては以下の2パターン。

• Simple AD(AWSに新規にディレクトリを作り、そこで管理する)
• AD Connector(オンプレ側に既存のADがあり、それを使いたい場合、AWSに接続できるようにする)

Security Token Service(STS)

STSは限定的かつ一時的なセキュリティ認証情報を提供するサービス。
IAMユーザーまたは認証済みのユーザーがSTSを発行し、外部の一時利用者に権限を与えるというもの。

Amazon Cognito

シンプルでセキュアなユーザーのサインアップ、サインイン、アクセスコントロールをアプリケーションに実装できる。
要はFirebase Authenticationみたいなやつで、フォームを作ってSDKとテンプレコードを導入すれば認証フォームいっちょ上がりというサービス。
認証フォームはセキュリティの基本かつ入口みたいなものなのに、アプリ制作においては1番疎かにしては行けない割には非常に面倒くさい(個人の感想かつモバイルアプリケーションやフロントエンドとサーバーエンドが分かれている場合は特に)ので、こうやって外部の認証システムを導入するのが確実ではあったりする。

インフラ保護

VPC。
サブネットの話、パブリックにリソースは置かずNATゲートウェイを設置してとプライベートサブネットを使うみたいなやつ。
パブリックはインターネットゲートウェイとの窓口(だからNATゲートウェイもここに置かれる)、プライベートはリソースを隔離または直接インターネットゲートウェイと通信しないための措置だった。

ちなみに

• セキュリティグループ……インスタンス単位で制御かつステートフルな仕組み
• ネットワークACL……サブネット単位で制御かつステートレスな仕組み

だった。
まあここはインスタンスそのものに大きく規制をかけるか、サブネットに対してさらに個別に制御を与えたいかという話になってくる。

検出制御

• CloudTrail(AWSユーザーに対してのモニタリング。行動ログの取得からガバナンス・コンプライアンスの管理及び運用とリスクの監査を行う)

• CloudWatch(AWSリソース及び実行アプリケーションに対してのモニタリングとメトリクスを行う)

• AWS GuardDuty(AWS上での悪意ある操作や不正な動作がないか継続的にモニタリングする脅威検出サービス)

• Amazon Inspector(自動でアプリケーションを検証し、脆弱性やAWSのベストプラクティスからの逸脱状況をチェックしてセキュリティ評価を行う)

• AWS WAF(可用性、セキュリティ侵害、リソースの過剰消費といった一般的なWebの脆弱性からアプリケーションやAPIを保護するファイアウォール)

• AWS Shield(マネージド型の分散サービス妨害(DDoS)に対する保護サービス。スタンダードとアドバンスドの2つのグレードがある)

• IAM Access Analyzer(外部エンティティと共有されているS3バケットやIAMロールなど、組織とアカウントのリソースを識別し、セキュリティ上のリスクであるリソースとデータへの意図しないアクセスを特定するサービス。つまり、IAMやロールによる権限が正常に利用されているか或いは間違った権限やロールを付与していないかを確認できる)

• AWS Security Hub(セキュリティアラートを一元管理することでコンプライアンスのチェックを自動化する。また、これを使った監査結果で修正すべき設定の数と現在のセキュリティ状態を把握することもできる)

モニタリングとセキュリティ危険の検出みたいな話。

AWS GuardDuty

VPCフローログ、CloudTrailログ、DNSログ等のログや悪意のあるIPやドメインリスト……といったセキュリティデータを分析して処理する継続的なセキュリティモニタリングサービス。
セキュリティデータが機械学習による解析を経て、レポーティングとして結果報告される。

ACM(AWS Certificate Manager)

Secure Sockets Layer/Transport Layer Security(いわゆるSSL/TLS)の証明書のプロビジョニング、管理、デプロイを実施できる。
主にSSL通信を行いたいリソースやサービス(ということはELB、Route53、S3、静的Webホスティングのインスタンス等ということになる)と連携して使うことになる。

例えばRoute53の場合はシンプルルーティング(レコードセットをAレコードで作ったりするやつとか)が基本的なルーティングの設定になるが、これにCNAMEレコードセットを作ってそこにACMで発行した証明書を充てがうことでドメインを所有していることを証明するみたいな使い方をする。
この証明書というのがDNSまたはメールで検証されてOKであった場合に発行されるので、CNAMEレコードを作ったあとはAレコードでインスタンスのIPアドレスを入力するのではなく、エイリアスを用いて通信ができるようになる(IPアドレス自体は利用している)
あとはELBにもこの証明書を使い(というよりELBでSSL通信を行うには必須)、セキュリティグループ等でhttpsを許可する設定をすれば完了。

コスト最適化

不必要なリソースを削減し、最適な料金選択をしろということでそのためのツールやサービスがこの領分にある。
おさらいとしては以下の通り。

• 不必要なリソース軽減
• 透明性のある費用賦課
• マネージド型サービスの利用
• 固定の償却コストを変動コストへと変換する
• スケールを適切に行い、コストメリットを模索する
• データセンターへの投資を不要にしていく

個々のサービスで例えばEC2ならリザーブドインスタンス、スポットインスタンス、テナンシー(インスタンスの分散のさせかた、要はデフォルトなのかハードウェア専有なのか、Dedicatedで物理サーバーから専有するのか)、ベアメタル(物理サーバーを専有してかつ、その物理サーバーに対してBTOみたいなことができるオプション)、Savings Plan(リザーブドとは別に1~3年の期間、特定の処理能力の範疇内で利用することを厳守することで安くなる)……と様々な利用方法があり、それをユースケースや利用目的に応じて適切に利用することを心がけようという話なのだが、例えばOrganizationsで一括請求をすることで

• メンバーアカウント間でリザーブドインスタンスを共有
• S3などの請求が複数アカウントで一括請求すると安くなる

といった方面のコスト最適化もできたりする。

あとはAWS Pricing Calculatorを使って見積もりをするという手段もある。
例えばAPI Gateway使いたいなとなったら、以下のようにサービスを選択してある程度のユースケースを設定して見積もることができる。

運用の優秀性

計画変更が起きた場合、或いは予期せぬイベントや障害の発生時において、自動化された運用実務とレビュー手順を文書化し、それをテストしてあるかどうかという概念。

• コード化された運用実行がある(環境自動化)
• ビジネス目的に沿った運用手順がある
• 定期的かつ小規模で増加的な変更管理をしている
• 予期せぬイベントへの対応テストの実施をしている
• モニタリングにより障害を予測する
• 運用上の失敗やイベントから学習する
• 運用手順を繰り返しアップデートする

主要なサービスとしては

• 準備段階……Cloud Formation、Codeシリーズ、Runbook、Playbook
• 運用……System Manger、Service Catalog、Cloud Trail、AWS Artifact、AWS Guard Duty、 Cloud Watch、AWS Config、API Gateway

となる。

AWS Config

ストラクチャの構成変更を管理するストリームと履歴管理をするヒストリー、構成要素を保存するSnapshotの機能とで構成される。

• Configuration Stream……リソースの作成・変更・削除に対して作成される。SNS Topicを使って通知させることもできる

• Configuration History……任意の期間における各リソースタイプの構成要素を履歴として蓄積する。保管場所はS3。

• Configuration Snapshot……ある時点での構成要素の集合。自動または定期的なトリガーで作成する。保管場所はS3。

AWS Service Catalog

AWSで承認されたITサービスのカタログを作成、管理するサービス。
IT運用管理者向けにCloud Formationのテンプレートを利用して、管理されるAWSリソース定義や、これらの利用権限をカタログとして一元管理できる機能とユーザー向けにカタログを使って権限がなくとも求める機能に応じたAWS環境を必要に応じて起動することが可能になるように支援をする。

AWS Artifact

重要なコンプライアンス関連情報の頼りになる一元管理型のリソース。

• AWS Artifact Reports……世界各地にある調査機関の指定する基準や規制を遵守しているかということを確認するためのテストを行い、結果をコンプライアンスレポートとして提供してくれる

• AWS Artifact Agreements……AWSアカウントとの契約の確認・受託・管理を実施してくれる

AWS Systems Manager

利用中のAWSサービスやリソースをモニタリングして運用タスクを自動化するサービス。
以下の4つの役割から構成される。

• 問題検出の時間短縮……リソースグループごとで運用データを確認することができるので、アプリケーションに影響を与えうるリソースの問題をすばやく特定可能

• 運用の自動化……EC2のパッチ、更新、設定変更、削除、停止、デプロイを自動化

• 可視化と制御……各リソースグループの最新状態を簡単に可視化して制御できる

• オンプレ側も管理できる……AWSサーバーとオンプレミスのサーバーとを一つのインターフェイスで管理可能

Cloud Watch

AWSリソースとAWSでで実行するアプリケーションのモニタリングサービス。
ログとメトリクスの監視を行う。
役割としては以下の6点。

• モニタリング
• 監視の集約化
• トラブルシューティング
• ログ解析
• 自動アクション
• 運用状況の確認

主な機能としては以下の3点。

• Cloud Watch……メトリクス監視を行う。具体的には死活監視、性能監視、キャパシティ監視

• Cloud Watch Logs……ログ管理プラットフォームサービス。EC2上のOSやアプリケーションのログやAWSマネージドサービスのログを取得する

• Cloud Watch Events……AWSリソースに対するイベントをトリガーにアクションを実行し、オペレーションの変更に応答したメッセージを送信したり、機能のアクティブ化、変更、状態情報収集による修正あk樹ションを実行してくれる

ちなみに機能が強化された有料版もある。
メトリクスは以下の2種類に分かれる。

• 標準メトリクス……CPUUtilization、ディスク使用率、読み込みIOPS……etc といった一般的なメトリクスを取得できる。取得間隔は5分間。

• カスタムメトリクス……拡張モニタリングを実行時に取得できるメトリクスたち。1秒から60秒でのリアルタイムでのメトリクス取得が可能

またCloud Watch ServiceLensを使ってマイクロサービスベースのアプリケーションやアーキテクチャ(Docker環境等、マイクロサービスベースの思想で分散が進んだ構成は通常のダッシュボードでは見にくい)をうまいこと可視化することもできる。

具体的には以下のサービスマップでマイクロサービスごとのメトリクスをマッピングして、

特にフィルタリングしたい場合は以下のトレースからフィルタリングする。

拡張モニタリングとは

DBインスタンスが実行されているOSのリアルタイムのメトリクスの取得が可能。
特徴としては以下の通り。

• 50種類以上のOSメトリクスを利用できる

• 1~60秒間隔までメトリクスの取得早めることができる(リアルタイムで取得できる)

• 取得したメトリクスはCloud Watch Logsに保存される

• 料金は無料枠を超えた拡張モニタリングに対してのみ発生する

• 拡張モニタリングはdb.m1.smallを除く全てのDBインスタンスで可能

• APIコール時のスロットリング対策にもなる

Cloud Watch Alarm

特定のメトリクスのしきい値に応じたアラーム通知や自動アクションを実行してくれる。

Cloud Watch Logs

ログの管理とその分析、可視化のためのサービス。
RDSのログにも対応している。

• EC2インスタンスの場合はエージェント経由でログメッセージをCloudWatchエンドポイントに転送する

• ログデータは1日から永久に保存期間を設定可能

• S3にログデータをエクスポートできる

• EC2インスタンスのログの場合は、エージェント経由でログメッセージをCloud Watchエンドポイントに転送する

• サブスクリプションフィルタ及びログのフィルタリングパターンによって、リアルタイムにKinesisやLambdaにログを送付するアクションを実施できる

Logsは以下の3つのレイヤーで構成される。

• ロググループ……ログの保存、管理のための設定を共有するためのグループ。複数のログストリームで構成される

• ログストリーム……モニタリングしているリソースのタイムスタンプ順でイベントを表す。複数のログイベントで構成される

• ログイベント……モニタリングしているリソースによって記録されているアクティビティレコード。イベント発生時のタイムスタンプとイベントメッセージによって構成される

Cloud Watch Logs Insights

ログデータを双方向に検索して分析する。

• クエリによってログを可視化・分析することが可能

• 以下の3つのフィールドを生成する

• @messageフィールドは生の未解決ログイベント

• @timestampフィールドはログイベントがCloud Watch Logsに追加された時間

• @logStreamフィールドはログイベントの追加先のログストリームの名前

• 時間軸に沿ってトレンドやパターンを可視化することが可能

• 可視化されたグラフをダッシュボードに追加できる

ハンズオン

KMS

いつも通りウィザードで設定。

オプションで外部からカスタムマスターキーをインポートしてKMSで利用することもできる。

あとは管理アクセスへの許可をどのユーザーやロールなどに振るかと、

同じようにキーの使用アクセスへの許可を設定して

確認画面でキーポリシー等を確認して出来上がり。
キーポリシーは自分で編集することもできる。

出来上がるとコンソールに表示され、

いつものように詳細も見れる。

作ったあとはRDSなどで選択できるようになる。

ACM

利用にはドメインが必須。

証明書の発行には検証が必須。

ELBでのssh通信の設定にはこの証明書が必須。

CloudWatch

ロググループ作るときにRoleが必要だが、自動で作ってくれない場合があるのでその場合は こちら を参考に作成する。

メトリクスの作成

リソースやサービスを選んで

メトリクスしたい項目を選択(複数も可)

あとは条件を設定して

完成。

このメトリクスをダッシュボードに貼り付けることで複数のメトリクスを同時に管理することもできる。
以下のように可視化の方法も選べる。

リソースにルールを作ってそれに則ってSNS通知をする。

まずTopicを作ってサブスクリプションしておく。

次にルールを作る。
今回はEC2インスタンス(すべての)の状態が変更されたらSNS Topicで通知するというルールになる。
ちなみに下記のようにSNS以外でもターゲットにすることができる、例えばルールをトリガーにしてLambda関数を発火にするなど。


設定するとこのようにコンソールに表示される。

実際にEC2インスタンスを停止してみると以下のように通知が来る。

ロググループ

まずは作成。

次にEC2インスタンスのフローログを取ってみる。
まずはネットワークインターフェイスへ飛び、

対象を選択して、フローログを作成する。

ウィザードで作成。
ただし、Roleが必要なので先述の通りなければ自力で作る。

作成完了。

あとはログが溜まればこのように表示される(画像はRDSログのもの)

Insightでクエリ実行することでフィルタリングすることもできる。