AWS Config 入門
どんなサービス？
AWS リソース(モノ)の設定、変更を記録して履歴として確認できるようになる。また、AWS Config ルールを作成すれば、設定内容がルールに準拠しているか評価して、非準拠なら Amazon SNS で通知できる。
また、特定の AWS リソースを使用するすべてのリソースを確認できる。(あるセキュリティグループを使っている全てのインスタンスを確認する等)
コンプライアンス監査や、セキュリティ分析、リソース変更の追跡、トラブルシューティングを可能とする。
どうやって設定を評価するの？
AWS Config ルールを作成して評価内容を定義する。
AWS Config ルールにはマネージドルールというカスタマイズ可能な定義済みのルールが用意されているが、独自のカスタムルールを作成することもできる。
AWS Config はリソースで発生する設定変更を継続的に追跡し、これらの変更がルールの条件に違反している場合はリソースとルールに非準拠を示す [noncompliant] のフラグを付ける。
評価の対象にできるリソースは以下の3つ。
- タグキー
- リソースタイプ
- リソースID
評価のトリガーは以下の2種類。
- 設定変更
- ルールの範囲に該当するリソースで設定が変更されたとき (設定レコーダーが有効のとき)
- 定期的
- 指定した間隔 (選択可能な頻度は 1 時間、3 時間、6 時間、12 時間、24 時間)
サービスの開始方法
コンソールおよび AWS CLI で開始可能。 アカウント内のリージョン単位で操作が必要。
ルールの有効化方法
標準で最大 150 個のルールを作成できる。
利用するメリットは？
- 初期費用なしでリソースの設定を簡単に追跡できる。
- データ収集のためのエージェントをインストールおよび更新したり、大規模なデータベースを管理したりといった複雑な作業を回避できる。
- 特定の規準 (PCI-DSS、HIPAA など) に準拠させる必要があるワークロードを持っている場合は、Config ルールの機能を使用して AWS インフラストラクチャ設定のコンプライアンスを評価し、監査人に向けてレポートを生成できる。
マルチアカウント、マルチリージョンでのデータ集約について
AWS Config のデータ集約機能では、複数のアカウントやリージョンの AWS Config データを単一のアカウントに集約できる。これは純粋に、コンプライアンスの可視性を実現するレポート機能である。
AWS Config の新しいリソースタイプであるアグリゲータで複数のアカウントやリージョンから AWS Config データを収集する。
AWS Organizations は利用していなくても良い。
EC2 インスタンス内のソフトウェアに対する設定変更について
AWS アカウント内の EC2 インスタンス内に加え、オンプレミス環境の仮想マシン (VM) やサーバー内のソフトウェアに対する設定変更を記録できます。
- AWS Config で記録される設定情報
- オペレーティングシステム更新
- ネットワーク設定
- インストール済みのアプリケーション
以前にコンプライアンス違反であったリソースが依然としてコンプライアンス違反である場合の挙動
AWS Config は、コンプライアンス状況に変化があったときにのみ通知を送信します。以前にコンプライアンス違反であったリソースが依然としてコンプライアンス違反である場合、Config は新しい通知を送信しません。コンプライアンス状況が「コンプライアンス遵守」に変化した場合、状況変化の通知がお客様に届きます。
AWS Config を使って S3 バケットのパブリックアクセスが可能となった場合に通知する方法
できないこと
- リソースをプロビジョニングする前、またはリソースの設定を変更する前にルールによる評価を実行すること
- データ集約機能を使って複数アカウントにルールをプロビジョニングすること
課金のタイミング
- 記録対象のリソースタイプで変更を検出した回数
- 月ごとにアクティブだった AWS Config ルールの数
AWS Organizations 入門
AWS Organizations とは
複数の AWS アカウントを統合するためのアカウント管理サービス。
実現できること
- AWS アカウントのグループを作成し、作成したグループにポリシーを適用して、利用サービスを制限できる
- AWS アカウントの新規作成は自動化できる
- 複数の AWS アカウントの請求を一括して、請求を簡素化できる
AWS Organizations の構成
- 管理者として使用するAWSアカウントを一つ選び、組織を作る。
- 選んだAWSアカウントはマスターアカウントとなり、組織の全体を管理する権限を持つ。
- 組織内のマスターアカウント以外はメンバーアカウントとなる
- 組織には複数AWSアカウントのグループ(OU)を作成できる。
- OUにはAWSアカウントを作成、追加することができる。
- OUからアカウントを削除した場合、アカウントは組織からは外れるが独立したたアカウントとなり、個別に請求などが開始される。アカウント自体が消されるわけではなく、使い続けれる。
- OUの開始点は管理用ルートとなる。
- 組織内の権限はポリシーで制御することができる。
- サービスコントロールポリシー(SCP)はIAMと同じ構文ルールで登録する
一括請求(Consolidated Billing)について
- ボリュームディスカウントが合算して計算される
- リザーブドインスタンスによる割引がデフォルトで共有(共有しないように設定も可能)
- 各アカウントの請求額は確認可能。リザーブドインスタンスによる割引が共有された状態での請求額となるが、使用状況レポートでは割引を共有しない場合の料金(Unblended Rate)も確認可能。
利用シーン
AWSの支払いを代行してほしい
- AWS Organizationsで作成したアカウントを提供するか、既存のアカウントを組織に招待して統合します
- 代行者はマスターアカウントで利用料を支払い、費用を請求します
プロジェクトの環境を本番、ステージング、開発の3つに分けて管理したいんだけど
- AWS Organizationsでそれぞれの環境用のアカウントを作成しましょう
社員にAWSの検証環境を配布したい
組織からアカウントを削除したら使えなくなる？
- アカウント自体は削除されないので大丈夫です
- アカウントが独立するので個別に請求されないように注意
参考
www.slideshare.net
Amazon Inspector 入門
Amazon Inspectorって？
自動化されたセキュリティ評価サービス。 Amazon EC2 インスタンスのネットワークアクセスと、そのインスタンスで実行しているアプリケーションのセキュリティ状態をテストできる。
Amazon Inspector を使用すると、どのようなことができるのですか？
開発およびデプロイパイプライン全体で、または静的な本番システムに対してセキュリティ上の脆弱性の評価を自動化することができます。これにより、セキュリティテストを開発および IT オペレーションの通常の一部にすることができます。
評価結果はリストが作成される。 Amazon InspectorコンソールやAPIを介して詳細な評価レポートを入手できる。
Amazon Inspector の利点
- 自動セキュリティチェックを通常のデプロイおよび本番プロセスに統合
フォレンジック、トラブルシューティング、またはアクティブな監査目的のために AWS リソースのセキュリティを評価します。
- アプリケーションのセキュリティ問題を発見
アプリケーションのセキュリティ評価を自動化し、脆弱性を予防的に特定しますこれにより、新しいアプリケーションの開発と反復実行を迅速に行い、ベストプラクティスやポリシーへのコンプライアンス状況を評価できます。
- AWS リソースのより深い理解
mazon Inspector が生み出す調査結果を確認して、AWS リソースのアクティビティおよび設定データについて常に情報を入手できる。
Amazon Inspector の評価
事前に定義されたルールパッケージを使用でき、こうしたルールパッケージは一般的なセキュリティのベストプラクティスと脆弱性の定義にマッピングされています。
Amazon Inspector の評価テンプレート
評価の実行を定義するために、ユーザーは Amazon Inspector で評価テンプレートを作成する。この評価テンプレートには、以下を割り当てる。
- 評価ターゲットを評価するためのルールパッケージ
- 評価実行時間
- 15 分
- 1 時間 (推奨)
- 8 時間
- 12 時間
- 24 時間
- 評価の実行状態と結果に関する通知の送信先である Amazon SNS トピック
- 評価の実行によって生成された結果を割り当てることができる Amazon Inspector 固有の属性 (キー/値のペア)
ルールパッケージとは何ですか?
ルールパッケージは、評価テンプレートと評価の実行の一部として構成されるセキュリティチェックのコレクションです。Amazon Inspector のルールパッケージには、Amazon EC2 インスタンスについてネットワークのアクセス可能性をチェックするネットワークの到達可能性ルールパッケージと、Amazon EC2 インスタンスの脆弱性と問題のある設定をチェックするホスト評価のルールパッケージの 2 種類があります
Amazon Inspector の評価の実行とは？
評価の実行は、指定したルールパッケージを使用して評価ターゲットの構成、インストールされたソフトウェア、動作を分析し、潜在的なセキュリティ上の問題を発見するプロセスです。
Amazon Inspector の評価実行中にパフォーマンスへの影響はありますか?
ネットワークの到達可能性のルールパッケージを使用してエージェントレス型の評価を実行する場合、アプリケーションのパフォーマンスに対する影響はありません。Amazon Inspector エージェントを使用すると、評価実行時のデータ収集フェーズにおけるパフォーマンスへの影響を最小限に抑えることができます。
評価ターゲットとは？
評価対象となる Amazon EC2 インスタンスの集合。 すべてのインスタンスを評価ターゲットに含めることも、Amazon EC2 タグを使用して一部のインスタンスを指定することもできます。
評価の実行中に検出された潜在的なセキュリティ上の問題を所見と呼ぶ。 所見は Amazon Inspector コンソールに表示されるか、API を介して検索、およびセキュリティの問題の詳細な説明およびそれを修正する方法についての推奨事項の両方を含んでいます。
脆弱性の分析対象となるソフトウェア
OSのパッケージマネージャーでインストールされたソフトウェアの脆弱性を評価する。
評価について
| 評価の種類 | ルールパッケージの種類 | 内容 | EC2インスタンスのエージェントの有無 |
|---|---|---|---|
| ネットワーク評価 | ネットワークの到達可能性 | EC2 インスタンスについてネットワークのアクセス可能性をチェックする | 不要 (有ればより詳細な評価レポートを生成) |
| ホスト評価 | 共通脆弱性識別子、Center for Internet Security (CIS) ベンチマーク、Amazon Inspector のセキュリティのベストプラクティス、実行時の動作の分析 | EC2 インスタンスの脆弱性と問題のある設定をチェックする | 必要 |
- NAT を使用しているインスタンスの評価もサポートしており、ユーザーの設定は必要ない。
- プロキシ環境はLinuxならHTTPSプロキシを、WindowsならWinHTTPプロキシがサポートされている。
エージェントの導入方法
- マニュアルでインストール
- AWS Systems Manager Run Command ドキュメント (AmazonInspector-ManageAWSAgent) を用いて一回きりのロード
- EC2 User Data Function を用いて自動エージェントインストール
- AWS Lambda を用いてエージェントの自動インストール
- EC2 コンソールまたは AWS Marketplace から予めインストールされた Amazon Inspector エージェントと共にAmazon Linux AMI を用いて EC2 インスタンスを起動
制限
| リソース | デフォルトの制限 |
|---|---|
| 評価ターゲット | 50 |
| 実行しているエージェント | 500 |
| 評価点プレートの数 | 500 |
| 評価の実行の作成数 | 50,000 |
fluentd を使って S3 にログを集約する
環境
| ソフトウェア | バージョン |
|---|---|
| Ubuntu | 16.04 |
| td-agent | 1.2.6 |
| Apache | 2.4 |
期待値
apache のアクセスログを s3 のバケット内に保管する。
設定方法
1. Fluentd をインストール
インストールスクリプトが公開されているため実行してインストールする。 URLにOSのバージョンが含まれているため、インストール対象のOSバージョンに合ったURLを確認すること。
Ubuntu のバージョン確認
$ cat /etc/os-release NAME="Ubuntu" VERSION="16.04.5 LTS (Xenial Xerus)" ID=ubuntu ID_LIKE=debian PRETTY_NAME="Ubuntu 16.04.5 LTS" VERSION_ID="16.04" HOME_URL="http://www.ubuntu.com/" SUPPORT_URL="http://help.ubuntu.com/" BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/" VERSION_CODENAME=xenial UBUNTU_CODENAME=xenial $
インストール実行。
curl -L https://toolbelt.treasuredata.com/sh/install-ubuntu-xenial-td-agent3.sh | sh
td-agentがインストールされる。fluentdではない。
$ which td-agent
/usr/sbin/td-agent
$
$ td-agent --version
td-agent 1.2.6
$
2. Fluentdの設定
/etc/td-agent/td-agent.confを編集する。
対象となるログについて指定するsourceとログの出力設定を指定するmatchを設定する。
apache2 のログを転送対象にする。
<source> @type tail path /var/log/apache2/access.log tag td.apache2.access pos_file /var/log/td-agent/apache2.access.log.pos format apache2 </source>
続けてログをS3へ転送する設定も追記する。
<match td.apache2.access> @type s3 s3_bucket logi-fluentd s3_region ap-northeast-1 time_slice_format %Y%m%d%H%M </match>
今回使用しないmatchをコメントアウトする。(残したままにしているとエラーになったため)
#<match td.*.*> # @type tdlog # @id output_td # apikey YOUR_API_KEY # # auto_create_table # <buffer> # @type file # path /var/log/td-agent/buffer/td # </buffer> # # <secondary> # @type file # path /var/log/td-agent/failed_records # </secondary> #</match
ログに対するアクセス権限でエラーにならないようにする。
/etc/init.d/td-agentを編集し、以下の箇所をrootに変更する。
TD_AGENT_USER=root TD_AGENT_GROUP=root
EC2にS3に対する書き込みを許可するIAMを設定する。
今回は検証なのでAmazonS3FullAccessのポリシーで設定。
fluentd のプロセスを再起動する。
$ sudo /etc/init.d/td-agent restart
apache にアクセスしてしばらく待つと、S3 に ログが保管されていることを確認できた。
docker + nginx + uwsgi + flask の構築
環境
| software | version |
|---|---|
| Ubuntu | 18.04 |
| Docker | 18.09.0 |
| docker-compose | 1.23.2 |
ディレクトリ構成
┣ myServer
┣ app
┣ Dockerfile
┣ main.py
┣ requirements.txt
┣ uwsgi.ini
┣ docker-compose.yaml
┣ nginx
┣ Dockerfile
┣ nginx.conf
1. docker-compose.yamlの作成
version: "3" services: uwsgi: # ビルドするDockerfileのでディレクトリ相対パス build: ./app # 指定したパスをコンテナにマウントする。"ホストのパス:コンテナのパス"となる volumes: - ./app:/var/www/ # 解放するポートを指定。"ホスト:コンテナ"のマッピング となる ports: - "3031:3031" # コンテナ内の環境変数を指定する environment: TZ: "Asia/Tokyo" nginx: build: ./nginx volumes: - ./nginx/nginx.conf:/etc/nginx/nginx.conf # nginxのログをホストOSの /tmp/nginx_log に出力する - /tmp/nginx_log:/var/log/nginx links: - uwsgi ports: - "4231:80" environment: TZ: "Asia/Tokyo"
2. app の設定
Dockerfile
# ベースイメージ FROM python:3.6 RUN mkdir /var/www # workdirの指定 WORKDIR /var/www # 依存Pythonライブラリ一覧コピー COPY requirements.txt ./ # 依存Pythonライブラリインストール RUN pip install --no-cache-dir -r requirements.txt CMD ["uwsgi","--ini","/var/www/uwsgi.ini"]
--no-cache-dir: キャッシュを無効にする-r:requirements.txtに記載されているパッケージを一括インストールする
main.py
from flask import Flask
app = Flask(__name__)
@app.route("/")
def hello():
return "Hello World!"
if __name__ == "__main__":
app.run()
requirements.txt
Flask uwsgi
uwsgi.ini
[uwsgi] wsgi-file = main.py callable = app master = true processes = 1 socket = :3031 chmod-socket = 666 vacuum = true die-on-term = true py-autoreload = 1
wsgi-file: Flaskアプリケーションファイルcallable: このファイル内のFlaskアプリケーションオブジェクトの名前master: オプションを指定すると、アプリケーションサーバーとして起動したとき、ソケットを閉じずに再起動したりできるようにします。processes: uWSGIの最大ワーカープロセス数socket: WEBサーバとWEBアプリケーションをつなぐポートもしくはUNIXソケットファイルを指定するchmod-socket: UNIXソケットのファイルパーミッション。指定が無い場合はデフォルトで 666 になるvacuum: プロセス終了時に生成されたすべてのファイル/ソケットを削除するdie-on-term: Upstartでプロセスが期待通りに処理されるために設定。uWSGIはプロセスを再ロードせずに強制終了します。py-autoreload: コードの自動リロード機能。チェックサイクルごとにモジュールツリー全体をスキャンします。
余談
filesocket (/file/path/uwsgi.sock) を使った nginx -> uWSGI の通信の確立の仕方が分からなかった。
試したこと
- server unix:///tmp/uwsgi.sock
- server uwsgi:/tmp/uwsgi.sock
参考
3. nginx の設定
Dockerfile
FROM nginx CMD ["nginx", "-g", "daemon off;", "-c", "/etc/nginx/nginx.conf"]
nginx.conf
user nginx;
worker_processes 1;
error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;
events {
worker_connections 1024;
}
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log /var/log/nginx/access.log main;
sendfile on;
#tcp_nopush on;
keepalive_timeout 65;
#gzip on;
upstream uwsgi {
server uwsgi:3031;
}
server {
listen 80;
charset utf-8;
location / {
include uwsgi_params;
uwsgi_pass uwsgi;
}
}
}
4. dockerコンテナのビルドと実行
docker-compose.yaml と Dockerfile の内容に従ってコンテナをビルドする。
$ sudo docker-compose build Building uwsgi Step 1/6 : FROM python:3.6 ---> 1ec4d11819ad Step 2/6 : RUN mkdir /var/www ---> Using cache ---> 0cba8c49bdd8 Step 3/6 : WORKDIR /var/www ---> Using cache ---> 8d210dacf801 Step 4/6 : COPY requirements.txt ./ ---> Using cache ---> 21c64fe227f5 Step 5/6 : RUN pip install --no-cache-dir -r requirements.txt ---> Using cache ---> 2836363b7b84 Step 6/6 : CMD ["uwsgi","--ini","/var/www/uwsgi.ini"] ---> Using cache ---> 1f55d63545b3 Successfully built 1f55d63545b3 Successfully tagged myserver_uwsgi:latest Building nginx Step 1/2 : FROM nginx ---> 568c4670fa80 Step 2/2 : CMD ["nginx", "-g", "daemon off;", "-c", "/etc/nginx/nginx.conf"] ---> Using cache ---> ac6b828f2312 Successfully built ac6b828f2312 Successfully tagged myserver_nginx:latest $
docker-compose.yaml のコンテナを実行する。
$ sudo docker-compose up -d Creating network "myserver_default" with the default driver Creating myserver_uwsgi_1 ... done Creating myserver_nginx_1 ... done $
-d: バックグラウンドで実行する
実行中のdockerコンテナのプロセスを確認。
$ sudo docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 28901248f4c9 myserver_nginx "nginx -g 'daemon of…" 53 seconds ago Up 52 seconds 0.0.0.0:4231->80/tcp myserver_nginx_1 860cd0fe644e myserver_uwsgi "uwsgi --ini /var/ww…" 54 seconds ago Up 52 seconds 0.0.0.0:3031->3031/tcp myserver_uwsgi_1 $
nginx にアクセスして検証する。
表示できた。
$ cat /tmp/nginx_log/access.log xxx.xx.73.51 - - [20/Dec/2018:14:49:10 +0900] "GET / HTTP/1.1" 200 12 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 OPR/57.0.3098.91" "-" $
アクセスログもホストOSで確認することができた。
