カテゴリー別アーカイブ: AWS

APIを利用したCloudWatchの設定

Pocket

こんにちは。配信/インフラチームの佐々木です。

弊社ではAWS上にシステムを構築していますが、前回お話しした通り監視ツールはCloudWatchを利用するケースが増えております。 今回はAPIを利用してCloudWatchを設定する手順をご説明します。

Alarmの設定

CloudWatchの用途としてインスタンスの監視に使うケースは多いと思います。そこでインスタンスのAlarmを設定するスクリプトを作ってみました。aws-cliとbotoどちらかを利用するのですが、今回はaws-cliで実装しています。

このように引数にNameタグを指定して利用します。

インスタンスIDで指定する方がシンプルな実装になるのですが、インスタンスIDはコピーペーストする必要がありますし、Nameタグの方がワイルドカード指定も出来て便利です。またアラーム名にもNameタグが入っていた方わかりやすくて良いと思います。ただNameタグが一意である必要がありますのでその点は注意が必要です。

Dashboardの設定

CloudWatchのDashboardもAPIを利用して設定することが可能です。その手順を記載します。

APIの仕様は以下になるのですが、元になる設定が無いと難しいと思いますので、適当なDashboardから定義をコピーします。ここでは2台のインスタンスのCPU使用率とNetworkInのメトリックを登録しています。

https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_PutDashboard.html

[アクション]の[ダッシュボードの編集]を選択すると、Jsonの定義を取得できます。ここから直接変更することも可能です。

コピーしたJsonを元に編集します。インスタンスを1台増やしてサイズも倍にしてみました。

作成したJsonファイルを以下のコマンドで適用します。

完成しました。

またこちらのページに、複数インスタンスを自動で登録するスクリプトが載っております。台数や取得するパラメータが多い場合などにはかなり有用かと思います。

https://aws.amazon.com/jp/blogs/news/new-api-cloudformation-support-for-amazon-cloudwatch-dashboards/

今回は以上になります。

AWS利用におけるIAMの設計

Pocket

こんにちは。配信/インフラチームの石田です。
現在DACから出向でユナイテッドでお世話になっております。
DACでも社内/サービス側両方のインフラ担当を担っております。

弊社では、AWSをDSP/SSPのサービスの基盤として利用しております。
また、AWSの利用者も、インフラチームや開発者、データ解析チームまで様々です。
「皆が同じルートアカンウトでログインし、全操作可能な状態」はセキュリティ的に問題があると考えております。

今回は、AWSのリソースアクセスコントロールを行い、セキュリティを向上する目的で導入したIAMの設計を紹介します。ルートアカウントでのAWSログインの廃止、CloudTrailでの操作ログ取得を実施するまでの過程を紹介します。

■IAMとは

IAMとは、Identity and Access Managementのことです。
ユーザーに対してAWSへのアクセスを安全に制御するための仕組みで、無料で導入できるのが魅力です。簡単に言うと、「AWSアカウントの中で、だれが何をできるかをコントロールするためのサービス」です。

■認証情報の種類

AWSにおける認証情報の種類としてはと下記の4つのクレデンシャルがあります。

  • AWSアカウントのパスワード
  • AWSアカウントのAPIキー
  • IAMユーザのパスワード
  • IAMユーザのAPIキー

■前提方針

前提条件としては、下記2つです。当然ですが、AWSルートカウントを利用しない方針でなければCloudTrailでの操作ログとして成立しません。

  • AWSルートアカウントはパスワードを変更し、利用しない。
    登録情報等の管理と請求関連操作にだけ使う。
  • AWSルートアカウントのAPIキーは利用しない。

■設計

今回弊社では、「管理者・開発者・運用者の役割を設け、開発者の自由度を考慮した設計案」を採用しました。基本的には、個人にポリシーを付与する形ではなく、グループにポリシーを付与する形式をとっております。また、ポリシーを個別に作成することも可能ですが、AWS側であらかじめ準備しているポリシーを利用します。

◉グループ
弊社では、AWS利用ユーザを3分類し、開発者の自由度を高く設計しております。

  • 管理者(Admin)
    →全サービス操作可能

  • 開発者(Developers)
    →IAM以外全サービスの操作可能

  • 運用者(Operators)
    →全サービスの参照のみ可能

◉ポリシー
今回は下記5つのポリシーを上記グループに付与する形で権限管理を行っております。

  • ”Administrator Access”
    →AWSアカウントに代わる強力な権限。全操作可能(既存)

  • ”Power User Access”
    →上記、Admin用からIAM操作権が省かれたポリシー(既存)

  • ”Read Only Access”
    →参照用ユーザ向けポリシー(既存)

  • ”ViewBilling”
    →請求情報参照用ポリシー(独自)

  • ”ChangePassword”
    →初回ログインPW変更可能ポリシー(独自)

◉グループとポリシーの関係
最終的なグループへの付与ポリシーは下記の通りです。

  • 管理者(Admin)
    ”Administrator Access”, ”ChangePassword”

  • 開発者(Developers)
    ”Power User Access”,”ChangePassword”

  • 運用者(Operators)
    ”Read Only Access”,”ChangePassword”,”ViewBilling”

■設定手順

–ユーザ作成編–

1)ルートアカウントでログインする。

2)IAMに移動し、ユーザを作成する。ユーザ名を入力し、「ユーザごとにアクセスキーを生成」にチェックを入れる。
iam-05

3)「認証情報をダウンロード」を選択し、アクセスキー、シークレットキーを保管する。

4)作成したユーザを選択し、認証情報タブを開き、「パスワードの管理」を選択する。
iam-06

5)初回ログイン時に必要になるユーザのパスワードを生成する。「自動作成パスワードの割り当て」を選択する。また、「次回のサインインで新しいパスワードを作成するようにユーザに求める」にチェックを入れる。
iam-07

6)「認証情報ダウンロード」から発行したパスワードを保管する。

–ポリシー作成編–

1)ルートアカウントでログインする。

2)アカウント>請求情報に対するIAMユーザアクセスの編集を選択する。
iam-01

3)請求情報に対するIAMユーザアクセスの「IAMアクセスのアクティブ化」にチェックする。
iam-02

4)IAMに移動し、ViewBillingポリシーの作成を行う。

5)ポリシーの作成>Policy Generatorを選択する。

6)アクセス許可の編集にて効果「許可」、AWSサービス「AWS Billing」、アクション「ViewAccount」「ViewBilling」にチェックを入れ, ステートメントを追加を選択する。
iam-03

7)ポリシードキュメントが作成されるので、「ポリシーの検証」を実行後、作成する。今回のポリシー名は「ViewBilling」とする。
iam-04

–グループ作成編–
1)ルートアカウントでログインする。

2)IAMに移動し、グループ>新しいグループの作成を選択する。

3)Admin には”Administrator Access”と”ChangePassword”を付与する。

4)Developersには”Power User Access”と”ChangePassword”を付与する。

5)Operatorsには”Read Only Access” と”ViewBilling”と”ChangePassword”を付与する。

–Cloud Trail編–
1)ルートアカウントでログインする。

2)Cloud Trailを選択する。
iam-07

3)証跡名、S3バケットを指定することでログ取得が可能になる。
iam-06

■まとめ

AWSのルートアカウントでのログインを行っている人もまだまだ、多いと思います。
例えば、退職者が発生する度にAWSのルートアカウントのパスワードを変更するといった運用を続けるのはどうなのでしょうか。 AWSといった責任共有モデルでは、個々のセキュリティレベルの意識によってセキュリティレベルも大きく変わってきます。 今回のIAMの導入は、ユーザ、グループ、ポリシーといったコアな機能のみで構成されており、既存のポリシーを生かしつつ、簡単に導入できます。