refirio.org

AWSの初期設定

■IAMユーザの作成 IAM（Identity and Access Management）とはAWSにおける個別のユーザアカウント。 AWS登録直後はルートアカウントのみだが、アカウントの削除や権限の剥奪ができるように、原則としてIAMアカウントを使う。 二段階認証も設定することを推奨するが、以下のような事態には注意。 AWSのMFA用デバイスを紛失してサービス停止しそうになった話 - Qiita https://qiita.com/takano-h/items/f33e9a8a0350a5938e81 AWSのMFAを解除するためにアメリカ大使館に足を運んだ話 - Qiita http://qiita.com/kechol/items/9de7bbc607b5c608c77b 以下は実際に作業用ユーザを作成したときのメモ。 画面右上のアカウント名 → セキュリティ認証情報 → ユーザー → ユーザーを追加 ユーザー名: refirio-user AWSマネジメントコンソールへのアクセスを提供する: （チェックを入れる。） コンソールパスワード: （案件に合わせて選択。） パスワードのリセット: （案件に合わせて選択。） 「次のステップ: アクセス権限」をクリック。 ポリシーを直接アタッチする → AdministratorAccess にチェックを入れて「次のステップ: タグ」をクリック。 次の画面で必要に応じてタグを設定して「次のステップ: 確認」をクリック。（いったんタグは設定せずで大丈夫。） 確認画面が表示されるので、内容を確認して「ユーザーの作成」をクリック。 認証情報をCSVでダウンロードできるので、手元にダウンロードしておく。「閉じる」をクリックして完了。 ※「AdministratorAccess」でコンソールからひととおりの操作ができるが、 「マイアカウント」「マイ請求ダッシュボード」など一部の情報にはアクセスできなくなる。 ■IAMユーザの作成（より操作が限定されたユーザを作る場合の例1） S3のみ操作できるユーザを作成してみる。 画面右上のアカウント名 → セキュリティ認証情報 → ユーザー → ユーザーを追加 ユーザー名: s3-user アクセスの種類: AWS マネジメントコンソールへのアクセス コンソールのパスワード: （案件に合わせて選択。） パスワードのリセットが必要: （案件に合わせて選択。） 「次のステップ: アクセス権限」をクリック。 既存のポリシーを直接アタッチ → AmazonS3FullAccess にチェックを入れて「次のステップ: タグ」をクリック。 次の画面で必要に応じてタグを設定して「次のステップ: 確認」をクリック。（いったんタグは設定せずで大丈夫。） 確認画面が表示されるので、内容を確認して「ユーザーの作成」をクリック。 認証情報をCSVでダウンロードできるので、手元にダウンロードしておく。「閉じる」をクリックして完了。 これでS3のみ操作できるアカウントとなる。 AWSコンソールにログインして確認すると、EC2やRDSなどメニューには表示されるが、 「取得中にエラーが発生しました」「取得に失敗しました」 などのエラーになる。 ■IAMユーザの作成（より操作が限定されたユーザを作る場合の例2） 特定のS3バケットのみ、プログラムから操作できるユーザを作成してみる。 バケットの名前は「example-develop」であるとする。 画面右上のアカウント名 → セキュリティ認証情報 → ポリシー → ポリシーの作成 ポリシー名: ExampleDevelopS3Access 許可: 画面右上のアカウント名 → セキュリティ認証情報 → ユーザー → ユーザーを追加 ユーザー名: example-develop-app-user AWSマネジメントコンソールへのユーザーアクセス: 提供しない ポリシー: ExampleDevelopS3Access 以下のとおりアクセスキーを発行。 ユースケース: コマンドラインインターフェイス (CLI) Access key ID: XXXXX Secret access key: YYYYY 発行したアクセスキーで、SDKから「ファイルのアップロード」「ファイルのダウンロード」ができることを確認する。 【こんなときどうする？】特定のS3バケットにだけIAMからアクセスしたい | SunnyCloud https://www.sunnycloud.jp/column/20230107-01/ 特定のAmazon S3バケットにだけアクセスを許可する - JPCYBER https://www.jpcyber.com/support/create-iam-user-with-limited-s3-access ■IAMユーザの作成（請求を確認できるユーザを作成する） デフォルトではIAMユーザから請求情報を確認できない。 ただし「経理の人に請求だけは直接確認してもらいたい」のような場合に、ルートユーザを渡すのは避けたい。 これには、以下の手順で対応できる。 ルートユーザでAWSコンソールにログイン。 画面右上のメニューから「アカウント」に遷移。 遷移先の画面下部に「IAM ユーザーおよびロールによる請求情報へのアクセス」の項目がある。 デフォルトでは「無効化済み」となっているので、編集ボタンからアクティブ化する。 ポリシー「AWSBillingReadOnlyAccess」が付与されると、請求情報にアクセスできるようになる。 ここではIAMユーザ「billing-user」を新規に作成し、上記のポリシーをアタッチする。 （ポリシー「AdministratorAccess」が付与されたユーザも、請求情報にアクセスできるようになる。） IAMユーザ「billing-user」でAWSコンソールにアクセスすると、請求情報を確認できる。 他の操作は許可されていないことも確認する。 [小ネタ]AWSアカウントの請求情報をIAMユーザに見せる方法 | DevelopersIO https://dev.classmethod.jp/articles/show-your-aws-billing-info-to-iam-users/ 【AWS】IAMユーザからアカウントの請求内容を見れるようにする | chibinet https://chibinfra-techblog.com/aws-billing-iam-setup/ 【AWS】IAMユーザーから請求情報にアクセスする方法 #AWS - Qiita https://qiita.com/ponponpoko/items/19c077d3133ff8922007 ■IAMユーザの作成（部分的に管理を委譲する） ※未検証。 AWS IAMの属人的な管理からの脱却【DeNA TechCon 2021】/techcon2021-19 - Speaker Deck https://speakerdeck.com/dena_tech/techcon2021-19 ■サインインリンクのカスタマイズ 作成したユーザは以下のようなURLから認証できる https://123456789012.signin.aws.amazon.com/console これでも問題ないが、カスタマイズして以下のようなURLから認証できるようにする。 複数の案件でアカウントを管理している場合、URLからどの案件なのか直感的に把握できるようになる。 https://refirio.signin.aws.amazon.com/console IAM → AWSアカウント → アカウントエイリアス → 作成 から優先エイリアスを登録でき、ここで登録した文字列が先頭の数字部分に反映される。 基本的にAWSアカウント名と同じにしておくと、余計な混乱がなくていい。 ■CloudTrail AWS CloudTrail（ユーザーアクティビティと API 使用状況の追跡）| AWS https://aws.amazon.com/jp/cloudtrail/ AWSの操作はコンソール・CLI・SDKなどを問わず、すべてAPIを通じて行われる。 そのためAPIの操作を監視しておけば、AWSにどのような方法で操作が行われても記録できる。 これを自動で行ってくれる。 CloudTrail → 証跡の作成 認証名: management-events（初期値のまま。） ストレージの場所 S3バケット: （初期値のまま。） 「証跡の作成」ボタンを押すと、S3にバケットが作成されて操作が記録されるようになるみたい。 AWS管理コンソールの不正ログインをCloudTrail と CloudWatch Logsで検知する http://dev.classmethod.jp/cloud/aws/aws-cloudtrail-cloudwatch-logs-badip/ 2017年8月から、CloudTrailがすべてのユーザーで自動的に7日間保管され、追跡できるようになった。 …とあるが、最初に「証跡の作成」は行っておくと良さそう。 CloudTrail が自動有効化されるようになったのに合わせて、設定方法を改めて眺めてみる - サーバーワークスエンジニアブログ http://blog.serverworks.co.jp/tech/2017/08/15/cloud-trail-all-customers/ ■GuardDuty Amazon GuardDuty（マネージド型脅威検出サービス）| AWS https://aws.amazon.com/jp/guardduty/ 料金 - Amazon GuardDuty | AWS https://aws.amazon.com/jp/guardduty/pricing/ 【全員必須】GuardDutyがコスパ最強の脅威検知サービスであることを証明してみた | DevelopersIO https://dev.classmethod.jp/articles/guardduty-si-strongest-thread-detection/ AWS利用料金の1〜2%程度で利用できるみたい。 いったん30日の無料トライアルで、自身のアカウントだと実際にどれくらいかかるかを試すといい。 GuardDuty → 今すぐ始める → GuardDutyの有効化 有効化すると、結果一覧に「結果がありません。」と表示された。 結果が表示されるまでには、少し時間がかかるみたい。 以下、結果が表示されるまでのメモ。 ・2022/05/09時点で有効にした。 ・2022/05/23時点で 「GuardDuty → 検出結果」を確認すると、「結果がありません。GuardDuty は継続的に AWS 環境を監視し、結果をこのページで報告します。」となっていた。 「GuardDuty → 使用状況」を確認すると、$0.27となっていた。 ・2022/06/01時点で 「GuardDuty → 検出結果」を確認すると、「Policy:IAMUser/RootCredentialUsage」が表示されていた。重要度は「低い」となっている。 「GuardDuty → 使用状況」を確認すると、$0.27となっていた。ただし「1日あたりの合計推定コスト」になっている。以前からこの表記だったか。 これは、ルートアカウントの利用が検知されているみたい。 ※2022/06/07時点で 「GuardDuty → 検出結果」を確認すると、「Policy:IAMUser/RootCredentialUsage」「Recon:EC2/PortProbeUnprotectedPort」が表示されていた。重要度は「低い」となっている。 さらに「Discovery:S3/TorIPCaller」も表示されていた。重要度は「高い」となっている。 「GuardDuty → 使用状況」を確認すると、$0.04となっていた。 GuardDutyでルートアカウントの利用を検知する | DevelopersIO https://dev.classmethod.jp/articles/guardduty-rootaccount/ コストは低いので有効化のままでいいかもしれないが、警告を自動で通知するような仕組みが必要か。 Security Hubなどと組み合わせる前提となるか。 [神アップデート]GuardDutyがEC2やECSのマルウェア検知時のスキャンに対応したので実際にスキャンさせてみた #reinforce | DevelopersIO https://dev.classmethod.jp/articles/guardduty-support-malware-protection/ マルウェアの検知に対応したらしい。 また改めて確認したい。 ■Macie Amazon Macie（機械学習による機密データの検出、分類、保護）| AWS https://aws.amazon.com/jp/macie/ 「メイシー」と読む。 S3のパケットが公開されていないか、パケットへのアクセス権限がどうなっているか。 など、S3の問題点を出してくれる。 オンにするだけでレポートを出してくれる。 個人情報を持っているバケットがあるなら使うといいみたい。 ■Config 現状の構成のスナップショットを取り、構成がどのように変更されたかを確認できる。 ただし少々高額なので注意。 Config → Get started Step1 Settings: デフォルト値のまま「Next」。 Step2 Rules: デフォルト値のまま「Next」。 Step3 Review: 内容を確認して「Confirm」。 以降、例えばセキュリティグループの設定を変更した場合などは、変更内容が記録されるようになるみたい。 AWS Configはとりあえず有効にしよう http://dev.classmethod.jp/cloud/aws/aws-config-start/ ■Security Hub AWS Security Hub（統合されたセキュリティ & コンプライアンスセンター）| AWS https://aws.amazon.com/jp/security-hub/ 料金 - AWS Security Hub | AWS https://aws.amazon.com/jp/security-hub/pricing/ AWS Security Hub を有効にすると AWS Config の利用料が倍増した話 - サーバーワークスエンジニアブログ https://blog.serverworks.co.jp/security-hub-increases-aws-config-cost AWS Security Hubで情報を集約！セキュリティ情報は一元管理する時代へ - ジード https://www.zead.co.jp/column/securityhub/ AWS Security Hubを活用した効率的でセキュアなマルチアカウント管理 - NRIネットコムBlog https://tech.nri-net.com/entry/multi_account_management_using_aws_security_hub 利用料金が高額になることがあるみたいなので、注意が必要みたい。 ConfigやGuardDutyなどを、別々に確認するのは大変なので、AWS Security Hubを使うといいらしい。 一つ一つログを見るのではなく、リスクの高いものからリストアップされるので、順番につぶしていけるらしい。 セキュリティベストプラクティスをどれくらい満たしているかも表示してくれるので、目安にはなる。 ■作業リージョンの選択 作業リージョンが「米国東部(バージニア北部)」になっているので、「アジアパシフィック(東京)」に変更しておく。 ■キーペアの作成 EC2 → キーペア → キーペアを作成 今回はキーペア名に「refirio」と入力し、作成。 ファイルの形式は「pem」でいいが、必要に応じて変更する。 ※AWSのアカウントを複数持つ可能性があるので、単に「AWS」や「EC2」という名前にしない方がいい。 よって「refirio-production」のような名前で作ると良さそう（案件名＋環境名）。 ■アカウント作成後の大まかな作業内容 ※備忘録にメモ ・ルートユーザとは別にコンソールの作業用ユーザを作成。 ・サインインリンクのカスタマイズ。 ・CloudTrailを有効化。（現在はデフォルトで有効化されている。） ・GuardDutyを有効化。（しておくと良さそうだが、詳細は引き続き要確認。） ・Configを有効化。（しておくと良さそうだが、少々高額なので注意。） ・Security Hubを有効化。（しておくと良さそうだが、まだ試したことは無い。） ・請求アラームを作成。 ・VPCを作成。 ・EC2の構築とElasticIPの割当。 ・RDSやなどを構築。 ・CloudWatch や CloudWatch Logs など監視を設定。 ・メール上限緩和＆逆引き(rDNS)設定の申請。（SESが使える案件ならSESを使う方がいい。その場合SESに関する利用申請を行う。） 以下を参考に、他に必要な作業があれば実施したい（要調査） AWSアカウントを作ったら最初にやるべきこと 〜令和元年版〜 ｜ DevelopersIO https://dev.classmethod.jp/cloud/aws/aws-1st-step-new-era-reiwa/ AWS アカウントの初期設定 - それ積んどく？ https://jigoku1119.hatenablog.jp/entry/2021/06/28/163810