はじめに
AWSCertifiedSysOpsAdministrator–Associate取得に向けて勉強したことのメモです。
やったこと
- whizlab
メモ
VPC
- IPv6
- IGWを作った後にルートテーブルの設定追加を忘れない（0.0.0.0/0）
- ネットワークACL
- セキュリティグループでは出来なかった「特定のIPアドレスを拒否する」ことが可能
- VPC の DNS サポート
- デフォルト以外の VPC 内にインスタンスを起動すると、プライベート DNS ホスト名がインスタンスに割り当てられ、VPC に指定した DNS 属性に応じて、およびインスタンスにパブリック IPv4 アドレスがある場合、パブリック DNS ホスト名が割り当てられる可能性があります。
- VPC には、VPC 内で起動したインスタンスがパブリック IP アドレスに対応するパブリック DNS ホスト名を受け取るかどうか、および Amazon DNS サーバーを通じた DNS 解決が VPC に対してサポートされるかどうかを決定する属性があります。
- subnetの設定で、自動でEC2インスタンスにGIPを振るかどうかを決められる
- VPCフローログ
AWS Direct Connect
- ネットワークの要件
CloudFront
- オリジンアクセスアイデンティティを使用して Amazon S3 コンテンツへのアクセスを制限する
- 特定バケットに特定ディストリビューションのみからアクセスできるよう設定する
- CroudFront以外に、S3コンテンツへ直接アクセスできるようになっていませんか？
- 配信元であるCloudFrontディストリビューションにオリジンアクセスアイデンティティ（OAI）を作成し、S3のバケットポリシーとしてそのオリジンアクセスアイデンティティからのリクエストだけ受け付ける設定にする
- ユーザは、CroudFront経由でのみアクセスできる
- OAIには、S3にアクセスできる権限を与える
- OAIをディストリビューションに追加する
- ディストリビューション
- オリジンサーバーでオブジェクトを保存した後、オブジェクトがどこにあるかをCloudFrontに伝える役目を持つディストリビューションを作成します。
- ディストリビューションを作成すると、CloudFrontはあなたがオブジェクトを管理する為に使用する一意のドメイン名を提供します。例えば、d111111abcdef8.cloudfront.netのような情報です。
EC2
- DBを組む場合
ELB
- 内部 Classic Load Balancers
- アプリケーションに複数のレイヤーがある場合 (インターネットに接続する必要があるウェブサーバーや、ウェブサーバーにのみ接続されているデータベースサーバーなど)、内部ロードバランサーとインターネット接続ロードバランサーの両方を使用するアーキテクチャーを設計できます。インターネット接続ロードバランサーを作成し、そこにウェブサーバーを登録します。内部ロードバランサーを作成し、そこにデータベースサーバーを登録します。ウェブサーバーは、インターネット接続ロードバランサーからリクエストを受け取り、データベースサーバー用のリクエストを内部ロードバランサーに送信します。データベースサーバーは、内部ロードバランサーからリクエストを受け取ります。
- ヘルスチェック
- 5秒間隔pingなど
- SurgeQueueLength
CloudWatch
- オンプレでも収集可能
- CloudWatch エージェントを使用して Amazon EC2 インスタンスとオンプレミスサーバーからメトリクスとログを収集する
- Windows Serverの場合、statsDを併用したり（CloudWatch Agentに組み込まれているので、有効化する）
- statsD: OSSの数値レポーティングツール。collectd的な。
- Metric Math を使用する
WAF
- https://dev.classmethod.jp/articles/aws-relearning2019-aws-waf/
- WAF全般のこと
- WAFに期待される主な働きは、悪意のある通信をブロックし、悪意のない通信を許可することです。実際に可能な動作は、通信がWAFを通過する時にルールに一致する場合はブロックまたは許可するものです。
- AWS WAFの基本
- AWS WAFで作成できるルールは4種類に分けられます。
Amazon GuardDuty
- https://dev.classmethod.jp/articles/guardduty-summary/
- GuardDutyとは
- セキュリティリスク
- インターネット上のリソースに対する攻撃リスク
- -> GuardDuty で独自の信頼された IP リストや脅威リストも使用するように設定することでカスタマイズできます。
- AWSアカウントへの攻撃リスク
- 具体的にはIAMのクレデンシャル情報
- インターネット上のリソースに対する攻撃リスク
- GuardDutyの原理と動作
Amazon Inspector
- 【Amazon Inspector とは？】初心者にもわかりやすく解説
- AWSのEC2 インスタンスにおいて脆弱性診断を自動で行ってくれるサービス
- 脆弱性診断を行うメリットとしては、実際のサーバに疑似的なサイバー攻撃を仕掛けることによって、本物のサイバー被害を受けることなくセキュリティのリスクを発見できる
- ただし、評価をするだけで脆弱性の対処はできません。
- Amazon Inspector と Amazon GuardDuty の違い
- Network Reachability
- EC2インスタンスがインターネット、仮想プライベートゲートウェイ、AWS Direct Connect、またはピアVPCなどの外部ネットワークから到達できるかどうかを判断するために、Amazon仮想プライベートクラウド（Amazon VPC）ネットワーク構成を分析します。
- つまり、ホストへの外部アクセスの可能性を通知します。これは、セキュリティグループ、ネットワークアクセスコントロールリスト（ACL）、ルートテーブル、インターネットゲートウェイ（IGW）など、すべてのネットワーク構成をまとめて分析することで、到達可能性を推測します。
- VPCネットワーク経由でパケットを送信する必要はなく、EC2インスタンスネットワークポートへの接続を試みる必要もありません。パケットレスネットワークマッピングや偵察のようなものです！
- -> これで到達可能か（SGの設定変更が失敗してないか等）をチェックし、CloudWatch Event ruleで通知する
- Inspector Agent が事前インストールされた AMI
AWS Trusted Advisor
- AWS Trusted Advisorは、「コスト最適化」、「パフォーマンス」、「セキュリティ」、「フォールトトレーランス」の４つの観点から、利用者のAWS環境をAWSが自動で精査し、推奨設定のお知らせをしてくれる機能です。
- EC2起動台数が制限台数以内に余裕を持って収まっているか
IAM
- Granting a User Permissions to Pass a Role to an AWS Service
- 多くの AWS サービスを設定するには、そのサービスに IAM ロールを渡す必要があります。これにより、サービスが後でロールの継承を行い、ユーザーの代わりにアクションを実行できるようになります。
- サービスにロールを渡すのはセットアップ時の 1 回限りで、サービスがロールを継承するたびに行うのではありません。
- たとえば、Amazon EC2 インスタンスで実行しているアプリケーションがあるとします。このアプリケーションには認証に使う一時的な認証情報と、AWS でアクションを実行するためのアプリケーション認証のアクセス許可が必要です。
- -> アプリケーションをセットアップする場合、こうした認証情報を提供するインスタンスを使用するため、EC2 にロールを渡す必要があります。
- -> そのロールに IAM ポリシーをアタッチして、インスタンスで実行するアプリケーションのアクセス許可を定義します。アプリケーションは、このロールが許可しているアクションを実行する必要があるたびに、ロールを引き受けます。
- ユーザーがロール (とそのアクセス許可) を AWS サービスに渡すには、そのサービスにロールを渡すアクセス許可が必要になります。
- -> これにより、承認済みのユーザーのみが、アクセス許可を付与するロールを使用してサービスを設定できるようになります。ユーザーが AWS サービスにロールを渡すには、IAM ユーザー、ロール、またはグループに PassRole アクセス許可を付与する必要があります。
- AWS アカウントの認証情報レポートの取得
- アカウントのすべてのユーザーと、ユーザーの各種認証情報 (パスワード、アクセスキー、MFA デバイスなど) のステータスが示された認証情報レポートを生成し、ダウンロードできます。
- IAMポリシーを利用することでEC2作成時、タグの付与を強制することができる
AWS Organizations
- https://qiita.com/atsumjp/items/57ce3cd17d78b5ac3df9
- AWS Organizationsは大きく分けて、Payerをまとめる機能とSCPにより認可設定する機能があります。
- SCPを付与する対象(エンティティ)は、組織のツリー構造のルートにあたるRootとOU（組織単位）とAWSアカウント
- 組織単位 (OU): ルート内のアカウントのコンテナ。
- SCP
- AWS Organizations 入門
- 管理者として使用するAWSアカウントを一つ選び、組織を作る。
- 選んだAWSアカウントはマスターアカウントとなり、組織の全体を管理する権限を持つ。
- 組織内のマスターアカウント以外はメンバーアカウントとなる
- 組織には複数AWSアカウントのグループ(OU)を作成できる。
- OUにはAWSアカウントを作成、追加することができる。
- OUからアカウントを削除した場合、アカウントは組織からは外れるが独立したたアカウントとなり、個別に請求などが開始される。アカウント自体が消されるわけではなく、使い続けれる。
- OUの開始点は管理用ルートとなる。
- 組織内の権限はポリシーで制御することができる。
- サービスコントロールポリシー(SCP)はIAMと同じ構文ルールで登録する
- 利用シーン
AWS Systems Manager
- AWS Systems Manager (SSM)はAWS上、オンプレミスに関係なくSSMエージェントが稼働するサーバインスタンスを一元管理するためのサービス。
- AWSコンソールからオンプレサーバを操作することもできたり
- ハイブリッド環境で AWS Systems Manager を設定する
- AWS Systems Manager ドキュメント
- yamlのcommandsの部分に実行したいコマンドを記載
- 依頼者と実行者が別、実行するタイミングが不明、履歴を残したい、コマンドにバグがあったら訂正も面倒、定期的に実行したいとかの場合もドキュメントとオートメーションは役に立つかと思います。
- (オプション) プライベートクラウドエンドポントの作成
- マネージドインスタンス (ハイブリッド環境のマネージドインスタンスを含む) のセキュリティ体制を改善するには、Amazon Virtual Private Cloud (Amazon VPC) でインターフェイス VPC エンドポイントを使用するように AWS Systems Manager を設定します。
- インターフェイス VPC エンドポイント (インターフェイスエンドポイント) を使用すると、AWS PrivateLink によって提供されるサービスに接続できます。
- これは、プライベート IP アドレスを使用して Amazon EC2 および Systems Manager API にプライベートアクセスできるようにするテクノロジーです。
- PrivateLink は、マネージドインスタンス、Systems Manager および Amazon EC2 間のすべてのネットワークトラフィックを Amazon ネットワークに限定します。(マネージドインスタンスはインターネットにアクセスできません)。
- また、インターネットゲートウェイ、NAT デバイスあるいは仮想プライベートゲートウェイの必要はありません。
- AWS Config Rules
- SGでポートを空けているやつがないかどうかチェック
- AWS Config ルールのトリガーの指定
- アカウントにルールを追加する際に、AWS Config でルールを実行するタイミングを指定できます。これは、トリガーと呼ばれます。AWS Config では、トリガーが発生すると、ルールを適用してリソースの設定を評価します。
- 2種類のトリガーがあります。
- 設定変更
- 定期的
- 設定レコーダーがオフになっているときのルールの評価
- 設定レコーダーをオフにすると、AWS Config ではリソースの設定変更の記録を停止します。これは以下のようにルールの評価ルールに影響します。
- 定期的トリガーのルールは、引き続き指定した間隔で評価が実行されます。
- 設定変更トリガーのルールでは、評価が実行されません。
- 両方のトリガータイプのルールでは、指定した間隔でのみ評価が実行されます。設定変更のルールでは評価が実行されません。
- 設定変更トリガーのルールのオンデマンド評価を実行すると、リソースの最後の知られている状態 (前回記録された設定項目) が評価されます。
- 設定レコーダーをオフにすると、AWS Config ではリソースの設定変更の記録を停止します。これは以下のようにルールの評価ルールに影響します。
- Document: Systems Managerでいう「ドキュメント」とは、自動実行される内容（≓スクリプト）を表す
- Patch Manager
- AWS Config
- Aggregate
- 複数のリージョン、複数のアカウントのリソースを取得できる
- 個別アカウントの承認処理は各リージョン毎に行う必要があるようです。ターゲットのアカウントで、各リージョンで AWS Config を有効化する都度、承認待ちになっていました。
S3
- Amazon S3 Glacier
- Amazon S3 Glacier (S3 Glacier) では、アーカイブを格納するコンテナをボールトと言います。
- アーカイブとは、ボールトに格納する写真、動画、ドキュメントなどのオブジェクトを指します。
- アーカイブは、S3 Glacier のストレージの基本単位です。
- ボールトを作成し、アーカイブをアップロードおよびダウンロードした後、最後にアーカイブおよびボールトを削除します。
- 「ロックポリシー」機能
- https://dev.classmethod.jp/articles/introduce-to-write-once-read-many-lock-on-amazon-glacier/
- Glacierに保存されたオブジェクトの書き換えや削除をAWSの機能として禁止させることができ、その期間も自由にポリシー設定することができるようになります。
- -> AWSは色々な企業の情報も扱うことが多いわけですが、企業にはそれぞれ情報に関するポリシーやコンプライアンスが定められています。その中には「情報の保存」も厳しく定められている事も多く、その情報が「書き換えられていないこと」「削除されていないこと」を証明するためにCloudTrail、S3のバージョン管理などの証跡サービスを使ったりします。しかし金融業などではそもそも「書換不能」「消去不能」なフォーマットで情報を保存するべし、という規則が定められています。今回のロックポリシーはこのような「絶対に書き換えられない」「絶対に削除できない」ポリシーを適用することで企業コンプライアンスをクリアできる、という場合や多人数、社外の会社さんに運用を頼む時等に絶対にログを消さないで欲しい、というようなケースの場合に「消えた時どうするか」ではなく「そもそも消えない」という状況を作り出すために使います。
- Amazon S3 サーバーアクセスのログ記録
- S3のアクセスコントロール
- https://dev.classmethod.jp/articles/s3-acl-wakewakame/
- ACL
- BucketPolicy
- Action, Effect, Principal, Resourceと、これらを組み合わせて柔軟なアクセスコントロールが実現出来ます。
- この一個のファイルだけを公開したいとかそういった用途に使うのには向いていないように思います。ObjectACLを使いましょう。
- 個人的な感覚ですが、bucketACLはBucketPolicyに置き換えたほうが良いなと思っています。
- IAM
- IAMとBucketPolicyの違いはユーザ（クライアント）側に紐付いて権限が与えられるということ
- どっちで管理した方が楽か。
- バケットが多い（増えていく）ならIAMとか
- 暗号化キー
- AWS KMS キーを使用した暗号化で、大容量ファイルを Amazon S3 にアップロードしようとしています。アップロードに失敗する理由は何ですか ?
- -> kms:Encrypt、kms:ReEncrypt、kms:GenerateDataKey、および kms:DescribeKey に対する許可も持っている必要があります。
- -> Amazon S3 はマルチパート アップロードを完了する前に、暗号化されたファイル パートからデータを復号化して読み込む必要があるため、このアクセス許可が必要です。
- キーポリシーと IAM アクセス許可の両方に対して、kms:Decrypt へのアクセス許可が必要
- サーバー側の暗号化の要求
Storage Gateway
- AWS Storage Gateway の仕組み (アーキテクチャ)
- ファイルゲートウェイ を使用するには、最初に ファイルゲートウェイ の VM イメージをダウンロードします。
- その後、AWS マネジメントコンソール からか Storage Gateway API により ファイルゲートウェイ をアクティブ化します。ファイルゲートウェイは、Amazon EC2 イメージを使用して作成することもできます。
- キャッシュ型ボリュームのアーキテクチャ
- 頻繁にアクセスされるデータはローカルのストレージゲートウェイに保持しながら、Amazon S3 をプライマリデータストレージとして使用できます。
- iSCSI デバイスとしてオンプレミスのアプリケーションサーバーにアタッチすることが可能
RDS
- Amazon RDS リソースの暗号化オプションを有効化すると、AES-256 暗号化アルゴリズムにより以下のデータを暗号化することができます。
- DB インスタンス
- 自動バックアップ
- リードレプリカ
- スナップショット
- ログ
- 暗号化オプションはDB インスタンスの作成時にのみ有効にすることができ、作成後のインスタンスでは有効にすることができません。ただし暗号化されていないスナップショットのコピーは暗号化することが可能です。
- Amazon RDS の暗号化されたインスタンスのリードレプリカも、同じ AWS リージョンにある場合にマスターインスタンスと同じキーを使用して暗号化されます。マスターとリードレプリカが異なる AWS リージョンにある場合には、その AWS リージョンの暗号化キーを使用して暗号化します。
Codeシリーズ
Cloud Formation
- cfn-signal ヘルパースクリプトは、Amazon EC2 インスタンスが正常に作成または更新されたかどうかを示すシグナルを AWS CloudFormation に送信します。
- Service Catalog
- https://www.idnet.co.jp/column/page_056.html
- CloudFormationで作成したテンプレートを登録しそのテンプレートをユーザに利用させることが出来るサービス
- Service Catalogの利用に必要なものは以下の3つです。
- ① IAMユーザ（またはロール、グループ）に割り当てるService Catalogの利用権限
- ② ③のテンプレートを利用するための権限を割り当てたロール
- ③ ユーザに利用させるCloudFormationテンプレート
QuickSight
- QuickSightにはSPICEというインメモリ型の高速データベースが内蔵されています。
- サポートされているデータソース
- IAMユーザに閲覧権を付与できる
- エンタープライズエディションなら
- ADを取り込める
- データの暗号化
コスト管理ツール
- AWS のコストと使用状況レポート (CUR)
- レガシー DBR を使用している場合は、レポートを コストと使用状況レポート に移行することを強くお勧めします。
- AWS CUR は、最も包括的な情報源を提供します。個々のコストを細かく把握し、詳しく分析できるため、特にエンタープライズ規模に役立ちます。AWS CUR は、専用のクエリや分析ベースのシステムなど、複雑なコスト管理のニーズを持つユーザーに最適です。AWS CUR は、特に償却費を確認する場合、リザーブドインスタンス (RI) の情報源としても最適です。
- 請求アラートを作成できる
- RI 使用率レポート
サポート
- AWS サポートのプラン比較
- Developer, Business, Enterprise
