AWSのAutoScalingの整理 スケーリングポリシー編

　AWS認定試験の対策本を書いていることもあって、試験についての相談を受けることがよくあります。その中で、AutoScaling関係の問題が難しいという相談が多い。話しを聞いていると、ELBの機能かAutoScalingの機能か切り分けて理解していないケースが多いようです。実務的には、ELBとAutoScalingは一体で使うことが多く、無理もないかなぁと思います。
　私も曖昧な理解している所が多かったので、改めてAutoScalingの機能について整理してみました。そうすると思っていた以上に多くの機能がアップデートされていて、定期的に知識のアップデートすることが必用だなと痛感させられます。ということで、今日はAWSのAutoScalingについて整理してみます。

EC2 AutoScaling

---

　EC2 AutoScalingは、EC2インスタンスの利用状況に応じて動的に増減させるサービスです。クラウドの特徴を活かした機能で、必用な時に必用なリソースを用意するというクラウドの象徴的な機能の一つではないでしょうか？私も初めてこの機能を使った時の感激はひとしおでした。さて、このEC2 AutoScalingには複数のスケーリング方法があり、次の3つの分類できます。

• 動的なスケーリング
• 予測スケーリング
• スケジュールスケーリング

一番代表的なのが、1つ目の動的なスケーリングです。動的なスケーリングには、更に3種類のスケーリングの設定方法があります。

• 簡易スケーリング
• ステップスケーリング
• ターゲット追跡スケーリング

簡易スケーリング

　1つ目の簡易スケーリングはCPU使用率が70%を超えたらといったように、１つのメトリクスに対して1つの閾値を設定します。簡易スケーリングという名前に変えられてしまいましたが、これが最初期のスケーリング方法です。古参のAWSユーザーには馴染みが深いのでは思います。で、実はこれは今は非推奨になっていて、簡易スケーリングを使いたい場合は、それよりも次で紹介するステップスケーリングを使うべきとなっています。

ステップスケーリング

　では、そのステップスケーリングです。ステップスケーリングは、1つのメトリクスに対して複数の閾値を設定します。例えば、CPU使用率が50%を超えた場合、60%を超えた場合と段階（ステップ）ごとの設定ができます。また、複数の閾値を設定できるものの１つの閾値のみを設定することもできます。つまり、簡易スケーリングの上位互換ということです。そのため、AWSとしては簡易スケーリングよりステップスケーリングを推奨しています。

AutoScalingグループの初期設定画面で、簡易スケーリングとステップスケーリングが選択できない

　と、ここまで来てAutoScalingグループの初期設定画面をみてみましょう。いつからかこうなっているのか解らないのですが、今では初期設定段階では簡易スケーリングもステップスケーリングも選択できなくなっています。これから紹介するターゲット追跡スケーリングか、スケーリングポリシー無しのどちらかです。AutoScalingグループなのにスケーリングなしって何だよと突っ込みたくなるかもしれませんが、例えば初期に設定した２台をずっと維持したい場合や、途中でインスタンスの障害が発生しても新たに立ち上げて２台を維持したいという場合、スケジュールスケーリングで時間に従ってインスタンスの増減させたい場合に効力を発揮します。

　では、簡易スケーリングとステップスケーリングは設定できないのかというとそうではなく、AutoScaling グループ作成後に設定変更で選択できるようにはなっています。またCLIでは、パラメータを指定すれば初期設定時点から指定ができます。AWSとしては、この２つではなくターゲット追跡スケーリングを使ってねという強い意志を感じますね。

ターゲット追跡スケーリング

　最後にターゲット追跡スケーリングです。1つのメトリクスに対して、目標値を設定します。例えばCPUの利用率を50%という目標値を設定すると、AutoScalingグループ全体でCPU利用率が50%を維持できるように自動的に調整されます。ステップスケーリングのように、細かく刻んで設定しなくてもAWS側があんじょうやってくれます。これは楽でいいですよね。従来ですとメトリクスに対してどのようにスケーリングさせるのかは、ある意味ノウハウでした。この辺りがお任せできます。

　ということで、EC2ダッシュボードの新UIで、AutoScalingの設定の動画です。ELBと連携させず、また起動テンプレートを設定済みという状況での作成の流れです。

EC2ダッシュボードの新UIでAutoScaling設定

起動設定と起動テンプレート

---

　ここまで読んで起動テンプレートってなんぞやと思った人もいるかと思います。起動設定じゃないのと。従来、AutoScalingグループは、起動設定を利用していました。今は、起動設定と起動テンプレートのどちらの指定も可能となっています。そして、新UIでは、起動テンプレートがデフォルトとなっています。つまり、起動テンプレートが推奨なのですね。
　起動テンプレートは、よく使うEC2の起動設定をテンプレート化して再利用しやすくするものです。一度、テンプレート化しておけば、二度目以降は台数指定するだけで同じ設定のものを起動できるようになります。この起動テンプレートは、別にAutoScalingグループのためだけにあるのではなく、通常のEC2の起動にも使えます。また設定内容も起動設定よりも細かく指定できるので、上位互換ですね。こちらもデフォルトになっていって、起動設定は恐らく緩やかにフェードアウトしていくのでしょう。

スケジュールスケーリング

---

　スケジュールスケーリングは、Auto Scalingの設定後にオプションで設定します。詳細画面の自動スケーリングタブの予定されたアクションから設定できます。

　指定の仕方は、Cron式や、5分毎・30分毎・1時間毎・毎日・毎週・一度の指定ができます。注意点としては、時間の指定はUTCであることと、一時的に増やした場合は対となる減らす設定も必用ということです。

AWS Auto ScalingとAmazon EC2 Auto Scaling

---

　ここまでがEC2のAuto Scalingグループのスケーリングポリシーの説明でした。最初に３つのスケーリングポリシーがあると言っていたものの、予測スケーリングがまだ出てきていません。実はややこしいことに、今現在のAWSのAuto Scalingは、AWS Auto ScalingとAmazon EC2 Auto Scaling、そしてApplication Auto Scalingの３種類があります。このうち、Application Auto Scalingは、ECSやEMRのクラスターやDynamoDBなどのアプリケーションのAuto Scalingを担当します。AWS Auto Scalingは独立したサービスのカテゴリーとして存在し、予測スケーリングはAWS Auto Scalingから設定することになります。AWS Auto Scalingは、管理カテゴリーに属するサービスとなります。

　EC2のAuto Scalingで予測スケーリングを利用する場合は、設定済みのAuto Scalingグループを指定します。その際は、スケーリングポリシーはなしにしておきましょう。

　そして、どういった方針に従ってスケーリングさせるかのスケーリング戦略を指定します。カスタムで細かく指定することも出来ますが、可用性最適化・コスト最適化などのデフォルトの戦略があるので、それを使うのも良いと思います。

　こういった感じで、AWS Auto Scalingを利用した予測スケーリングも簡単に指定できます。ただし、EC2の管理画面から離れているということもあり、初見では解りづらいというのもあるかと思います。そのうち、EC2のダッシュボードからも指定できるようになるのではという気がします。

まとめ

---

　かなり長くなってきたので、今回はここまでとします。AutoScalingは、実はAWS AutoScalingとApplication AutoScaling、Amazon EC2 AutoScalingの3つがあります。一般的にAutoScalingと言われているものは、Amazon EC2 AutoScalingだと思いますが、今後はカテゴリーとして独立しているAWS AutoScalingの機能拡張がされていきそうです。Amazon EC2 AutoScalingのスケーリングポリシーには、簡易スケーリング・ステップスケーリング・ターゲット追跡スケーリングの3つがありますが、AWSとしてはターゲット追跡スケーリングを推しているようです。実際、細かいことを考えずに充分使えるのでお勧めです。

　もともと猶予期間やウォームアップ・終了ポリシーなどの解説をしようとしたのですが、Auto Scalingのアップデートを追っているうちに長くなってしまいました。次回、Auto Scalingの細かい話を解説します。AutoScalingは、AWSを使いこなす上でも、AWSの認定試験の対策でも重要なテーマとなります。どういった設定ができるのか、またどういった時に使わけるのか、しっかりと理解しておきましょう。

AWSのAutoScalingの整理 猶予期間・ウォームアップ・終了ポリシー編 - プログラマでありたい

AWS認定資格試験テキスト AWS認定 ソリューションアーキテクト-アソシエイト

AWS認定 セキュリティ専門知識の対策本の書名・目次と書影

　今月7月29日発売のAWS認定 セキュリティ専門知識の対策本の書名や目次と書影がFIXしましたので紹介です。

要点整理から攻略する『AWS認定 セキュリティ-専門知識』

要点整理から攻略する『AWS認定 セキュリティ-専門知識』

書籍の内容について

共著者の上野さんと、私の方からそれぞれ書籍紹介のエントリーをあげています。書籍の内容については、こちらを参照ください。

fu3ak1.hatenablog.com

blog.takuros.net

表紙について

　表紙については、オレンジと黒を基調としたデザインです。帯の文言に『この1冊で身に付く！』とありますが、この本1冊読んだだけで合格するほどスペシャリティの試験は甘くありません。この本をガイドブックに、いろいろな資料・ドキュメントを読み、その上で実際に手を動かし経験を積むことによって合格レベルまでたどり着けます。という意味で、ちょっと不適切な文言なので、今後は直してもらうように調整しています。見落としており、初版は間に合わないのでご容赦ください。

目次

　最後に目次です。おおよそ試験範囲のところを網羅していると思います。マルチアカウントまでは出ないかなぁと思いつつ、セキュリティ上重要なのでカバーしております。

第1章　AWS試験概要と学習方法
　1-1　AWS認定試験の概要
　1-2　学習教材
　1-3　学習の進め方
　1-4　何に重きをおいて学習すべきか
第2章　IDおよびアクセス管理
　2-1　IAM
　2-2　AWS Directory Service
　2-3　AWS Organization
　2-4　Amazon Cognito
　2-5　AWS Organizations
　2-6　IDおよびアクセス管理に関するアーキテクチャ、実例
　2-7　IDおよびアクセス管理 まとめ
第3章　インフラストラクチャのセキュリティ
　3-1　AWS WAF
　3-2　AWS Shield
　3-3　AWS Firewall Manager
　3-4　Amazon Route 53
　3-5　Amazon CloudFront
　3-6　Elastic Load Balancing
　3-7　AWS Auto Scaling
　3-8　Amazon API Gateway
　3-9　Amazon Virtual Private Cloud
　3-10　Security Group
　3-11　AWS Artifact
　3-12　セキュリティに関するインフラストラクチャのアーキテクチャ、実例
　3-13　インフラストラクチャのセキュリティ まとめ
第4章　データ保護
　4-1　AWS Key Management Service (KMS)
　4-2　AWS CloudHSM
　4-3　Amazon Elastic Block Store (Amazon EBS)
　4-4　Amazon RDS
　4-5　Amazon DynamoDB
　4-6　Amazon S3
　4-7　Amazon Secrets Manager
　4-8　データ保護に関するアーキテクチャ、実例
　4-9　データ保護 まとめ
第5章　ログと監視
　5-1　Amazon CloudWatch
　5-2　AWS Config
　5-3　AWS CloudTrail
　5-4　AWS X-Ray
　5-5　Amazon Inspector
　5-6　S3に保存されるAWSサービスのログ
　5-7　Amazon Athena
　5-8　VPC Flow Logs(フローログ)
　5-9　Amazon QuickSight
　5-10　Amazon Kinesis
　5-11　Amazon Elasticsearch Service
　5-12　ログと監視に関するアーキテクチャ、実例
　5-13　ログと監視 まとめ
第6章　インシデント対応
　6-1　AWS Config
　6-2　AWS Systems Manager
　6-3　Amazon CloudWatch
　6-4　AWS Trusted Advisor
　6-5　AWS CloudTrail
　6-6　AWS CloudFormation
　6-7　Amazon Macie
　6-8　Amazon Guard​Duty
　6-9　AWS Security Hub
　6-10　Amazon Detective
　6-11　インシデント対応に関するアーキテクチャ、実例
　6-12　インシデント対応 まとめ
第7章　AWS Well-Architected
　7-1　AWS Well-Architected
　7-2　AWS Well-Architected まとめ
第8章　練習問題
　8-1　問題の解き方
　8-2　問題・解答

感想

　ちょうど今月、AWSソリューションアーキテクトのプロフェッショナルの対策本がでました。そして、今回セキュリティ専門知識の対策本を出すことが出来ました。日本語でも高度レベルの試験対策本が商業誌として出せるようになったのは喜ばしいです。AWSの利用者が増え、かつ高度レベルの受験者が増加しているという証左だからです。市場が育ってきたということに素直に喜びを感じます。
　一方でそもそも実務で鍛えた知識や経験を問うものだから、、こういったベンダー試験に試験対策本がそもそも必用なのかという議論はあるかもしれないのです。しかし、試験対策本があることにより受験への敷居を下げる効果があるのではと考えています。また、体系的・網羅的にまとまった本があることにより、短期間で効率的に勉強できるようになると思います。効率的な勉強方法がある事が、結果的にAWSのより良い利用方法を習得している人が増えることに寄与すると信じています。
　ちょっと他の宿題を片付けたら、他のスペシャリティやプロフェッショナルの対策本についても検討してみようかなと思います。

要点整理から攻略する『AWS認定 セキュリティ-専門知識』

AWS認定資格試験テキスト AWS認定 ソリューションアーキテクト-アソシエイト

IAMに有効期限を設定する条件式

　IAMの条件式に設定できるものを眺めていた時に、発見した小ネタです。
IAMではCondition要素で、そのポリシーが適用される条件が設定できます。
その中の1つに、有効期限を設定できる条件式があります。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "*",
            "Resource": "*",
            "Condition": {
                "DateGreaterThan": {"aws:CurrentTime": "2020-04-01T00:00:00Z"},
                "DateLessThan": {"aws:CurrentTime": "2020-06-30T23:59:59Z"}
            }
        }
    ]
}

DateGreaterThanで有効なる開始日時、DateLessThanで終了日時を指定します。日時の指定は、UTCです。

docs.aws.amazon.com

ユースケース

　一時的に許可を与える場合や、定期的にユーザー・ロールの棚卸しが必要な場合に良さそうですね。上の例では、有効期限で区切って許可ステートメントを与えていますが、○○日以降は全て許否（Deny）というポリシーを作って、グループやロールに追加するのが良いのではと思います。そうすることで、権限を制御するポリシーと有効期限を制御するポリシーを分離でき、権限ポリシーのパーツ化が図れます。図にすると、こんな感じですかね。

　このような形が良いと思うのは、IAMポリシーはできるだけパーツ化したいので、個人に紐付く有効期限等を権限管理と一緒にするのは避けたいからです。そして分離する場合は、許可じゃなくて許否にします。というのは、AWSのIAMのポリシーの評価論理としては、明示的許否　＞　明示的許可　＞　暗黙的拒否（デフォルト拒否）となっているからです。

　まぁこんな感じで使えるかなぁと思ったネタです。不要なIAMユーザーやIAMロールの定期的な削除は必要です。人間系の運用も必用となる部分なので、抜け漏れのヒューマンエラーを防ぐためにこういった手立てもよいのではないでしょうか？
　もう一歩組織としての管理が進むと、IAMユーザーは無くしてADによる認証とフェデレーションによるIAMロールの利用という形になるかと思います。全ての組織がそう出来るわけではないので、もし適合できるシチュエーションがあればご検討ください

AWS IAMの最小権限追求の旅

　皆さん、IAM使ってますか〜？
今日は、IAMのベストプラクティスの中に呪縛のように存在する、最小権限をテーマに悩みを語ってみようと思います。

IAMでのセキュリティのベストプラクティス

　まずは、IAMのベストプラクティスの確認です。2020年7月現在では、17個存在しています。一番最後のビデオで説明するの唐突感以外は、どれも納得感がある内容で実践・遵守すべきです。

docs.aws.amazon.com

1. AWS アカウントのルートユーザー アクセスキーをロックする
2. 個々の IAM ユーザーの作成
3. IAM ユーザーへのアクセス許可を割り当てるためにグループを使用する
4. 最小権限を付与する
5. AWS 管理ポリシーを使用したアクセス許可の使用開始
6. インラインポリシーではなくカスタマー管理ポリシーを使用する
7. アクセスレベルを使用して、IAM 権限を確認する
8. ユーザーの強力なパスワードポリシーを設定
9. MFA の有効化
10. Amazon EC2 インスタンスで実行するアプリケーションに対し、ロールを使用する
11. ロールを使用したアクセス許可の委任
12. アクセスキーを共有しない
13. 認証情報を定期的にローテーションする
14. 不要な認証情報を削除する
15. 追加セキュリティに対するポリシー条件を使用する
16. AWS アカウントのアクティビティの監視
17. IAM ベストプラクティスについてビデオで説明する

『最小権限を付与』する難しさ

　しかし、実際にこのベストプラクティスを実践していると、一つだけ難易度が格段に高いものがあることに気がつくでしょう。それは、『最小権限を付与する』です。最小権限には二重の意味の難しさがあります。

• 最小権限を適用するには、IAMの知識と探索の時間が必要
• 最小権限を探求するためには、IAMの権限が必要

　1つ目は言わずもがなかと思います。最小権限を付与するには、IAMを正しく理解している必要があります。その上で、実際に付与する際は、ポリシーを作って実際に動かしてみてと試行錯誤が必要です。これが結構、時間が掛かります。テクニック的な面としては、大きめの権限を最初に与えておいて、後でIAMの権限の利用履歴をみて絞り込むといった方法もありますが、それでも手間が掛かるでしょう。
　2つ目の探求するには、IAMの権限が必要という半ば禅問答的な問題です。最小権限を付与するためには、それ以上の権限を持っている人が実行しなければならないのです。組織的な話でいうと、ここが一番たいへんです。IAMを操作できる人を絞り込みたいし、付与する権限も最小限に抑え込みたい。でも、そうするとAWSのアカウントマネージャー的な立場の人が、ひたすらIAMの権限について考えないといけなくなります。
　昔であれば、そのモデルでも何とかなったかもしれません。しかし、今だとその方式でやると破綻する可能性が高いです。なぜなら、今のAWSの設計・開発は、IAMロールと向かいあう必要があるからです。

IAMロールと向き合う

　『IAMロールと向き合う』とはなんでしょうか？従来のAWSの構築は、VPCでネットワークを作ってその中にEC2をたててミドル・アプリの設計をしてという形が多かったかと思います。そのため、職能機能のAWS管理ポリシーに代表されるようなネットワーク管理者やデータベース管理者といった役割別の権限を付与して職務を遂行してもらうことになります。
　今は、それに加えてAWSのマネージドサービスを活用することが多くなっています。そういった際に、何が必要でしょうか？IAMロールをひたすら作ることが必要になってきます。IAMロールを作るには、IAMの権限が必要になります。IAMの権限とは、実質的に管理者の権限です。AdministratorAccessとPowerUserAccessの違いをみると解るのですが、IAMの権限があるかないかの違いしかないのです。
　という事でIAMは実質的に管理者権限で、IAMロールを作るにはその権限が必要になります。最小権限を作るために、最大の権限を渡すというこの矛盾に気が付いた瞬間に、体を引き裂かれるような思いをする事になります。
　

SCPとPermission Boundary

　AWSもその矛盾に気が付いていて、対策となるサービスを提供しています。AWS Organizationsのサービスコントロールポリシー(SCP）と、IAMのPermission Boundaryです、どちらも似たような機能を持ち、例えIAMの権限を持っていたとしても、予め許可した範囲しか権限が有効にならなくなります。次の図のように積集合ですね。

　このIAMのPermission Boundaryを使ってIAMロールは作れるけど、作れる範囲を限定するといった事ができます。詳しい手順はそのうち解説しようと思いますが、既にすばらしい解説記事があるので紹介しておきます。

qiita.com

　ただ、このPermission Boundaryを使いこなすのが中々難しいというのもあります。IAMをちゃんと理解して、どの範囲を許可するのか、その辺りの絶妙な設計が必要になります。人類のIAMレベルを上げないと、まだまだ万人向けでないのかなぁという印象です。私も、これでいいやという答えには達してないです。

サンドボックスアカウント

　もう一つの対策としては、サンドボックスアカウントという考え方があります。通常の環境と隔離したAWSアカウントを作り、その中でIAMの管理者権限を与え自由にやってもらう方法です。
　隔離したアカウントといえども、アクセスキー・シークレットアクセスキーなどセキュリティ・クレデンシャルの流失で、AWSアカウントが乗っ取られたら大事故が発生します。対策としては前述のSCPなどを利用して、これだけは防ぐという動作を禁止する方法があります。
　どちらも一長一短ですが、サンドボックスアカウントの方が、自由度が高く管理者の負荷は少ない傾向にあります。

そもそも『最小権限』とは？

　ここまで書いていて、実はそもそも『最小権限』の定義について、何も触れていないことに気がつくかもしれません。日本人的な几帳面さで、最小権限と聞くと字面そのままに、本当の最小権限を思い浮かべていると思います。例えば、S3への書き込み権限であれば対象バケットに対しての書き込み権限のみとか、オペレーターであれば参照権限とEC2等の起動・停止の権限のみとか。
　最近、ベストプラクティスの言う『最小権限』って、ここまで厳密な意味での最小権限と言っているのではないのではないかなと思えるようになってきました。例えば、開発者のそれぞれにAdmin権限渡さずに、職能機能のAWS管理ポリシーを付与するんだぞ〜的な大雑把さを指しているのではないかという気もしています。あるいは、個々のアクション単位の選定ではなく、ListやRead,Write,Permission Managementなどのアクセスレベルを指しているとか。
　あまり神経質に最小権限を追求して実現できないより、ある程度の大雑把さを許容している方が、現実的には運用は回るし事故も少ないと思います。その上で、本当に気を付けないといけないS3周りのパーミッション等を厳格に定義するのが良いのではないでしょうか。

まとめ？

　話が全然締まらずに横に外れていきましたが、IAMの最小権限の探究の悩ましさが伝わりましたでしょうか？一人で最小権限を追求してる時は、別にいいんですよ。セキュリティをどこまで追求するかも、それに掛ける工数も自分でコントロールできるから。でも、組織で運用するとなったら、途端に悩ましくなります。どこまで権限を委譲するのかの設計や、想定している委譲範囲から逸脱していないかの確認が必要になります。考え出すと止まらなくなるのが、『IAMの最小権限』です。ぜひ一緒に、この探求の沼旅に出かけましょう！！

booth.pm

booth.pm

AWS Control Towerとガードレールという設計思想

　前回、Control Towerの削除方法だけ書いていたので、それではあんまりだと思ったのでControl Towerの簡単な紹介とその中核の一つであるガードレールという設計思想を紹介します。

ガードレールという考え方

　従来の考え方では、セキュリティを保つためには多少の不便は仕方ないと、セキュリティと利便性とのトレードオフで語られることが多かったです。一方、AWSはガードレールという考え方を提唱し、『ブレーキをかけるのではなく、どんなスピードを出しても安全なセキュリティ』を確保しようという方策に舵を切っています。
　利便性とのトレードオフは、Gate（関所）と読んでいます。ガードレールは安全柵ですね。何度かお見せしてたかもしれませんが、関所とガードレールの違いを表した図になります。

ガードレールの実現手段としての予防と検知

　では、そのガードレールをどう実現しているのかというと予防（prevention）と検知（detection）です。予防は、事前に想定される危険性を定義して、そこからそもそも逸脱できなくすることです。実装例としては、個人レベルであればIAMに権限を与えないとかがあたります。またAWSアカウントレベルでは、AWS Organizationsのサービスコントロールポリシー（SCP）で制限するなどになります。
　予防に対して、検知とはなにでしょうか？検知は、セキュリティやガバナンス上で問題ある可能性がある動作を検出することです。例えば、VPCのネットワークの許可ポートの変更を検知したり、ルートユーザーの利用を検知したりとかが該当します。それだったら、検知じゃなく予防で防げばよいのではと思う人もいるかもしれません。しかし、検知の対象となる動作の大半は、実運用上でも必要なことが多いです。それを一律で防ぐのは難しいということで、検知して問題ないかを確認します。あとは、そもそも危険のある動作を全部洗い出して防ぐのも大変というのもあります。
　予防と検知の関係を図でまとめると、次のようになります。

Control Towerでの予防と検知

　では、Control Towerでは、予防と検知をどのように実装しているのでしょうか？実は、Control Tower自体には直接的な予防と検知の機能を持ちません。予防はOrganizationsのサービスコントロールポリシー（SCP）で実現し、検知はConfig Rulesで実現しています。Control Towerを有効にすると、自動的にこれらの機能をオンにして初期設定をしてしまうのです。そして、状況を収集するようになるといった感じです。
　では、Control Towerが初期設定する設定をみてみましょう。まぁほとんどが予防ですね。ということで、Control TowerがOrganizationsを作るのも納得です。

名前	ガイダンス	カテゴリ	動作
ログアーカイブの削除を許可しない	必須	監査ログ	予防
ログアーカイブの保存時に暗号化を有効にする	必須	監査ログ	予防
ログアーカイブのアクセスログ作成を有効にする	必須	監査ログ	予防
ログアーカイブへのポリシーの変更を不許可にします	必須	モニタリング	予防
ログアーカイブへのパブリック読み取りアクセス を不許可にする	必須	監査ログ	検出
ログアーカイブへのパブリック書き込みアクセス を不許可にする	必須	監査ログ	検出
ログアーカイブの保持ポリシーを設定する	必須	監査ログ	予防
CloudTrail への設定変更を不許可にします	必須	監査ログ	予防
CloudTrail イベントと CloudWatch logs を統合する	必須	モニタリング	予防
利用可能なすべてのリージョンで CloudTrail を有効にする	必須	監査ログ	予防
CloudTrail ログファイルの整合性検証を有効にする	必須	監査ログ	予防
AWS Control Tower によって設定された CloudWatchへの変更を不許可にします	必須	Control Tower のセットアップ	予防
AWS Config 集約承認の削除を許可しない	必須	Control Tower のセットアップ	予防
AWS Control Tower によって設定された AWS Config アグリゲーションへの 変更を不許可にします	必須	Control Tower のセットアップ	予防
AWS Config への設定変更を不許可にします	必須	監査ログ	予防
利用可能なすべてのリージョンで AWS Config を有効にする	必須	監査ログ	予防
AWS Control Tower によって設定された AWS Config ルールへの変更を不許可にします	必須	Control Tower のセットアップ	予防
EBS 用に最適化されていない EC2 インスタンスタイプの起動を許可しない	強く推奨	オペレーション	検出
EC2 インスタンスにアタッチされていない EBS ボリュームを許可しない	強く推奨	オペレーション	検出
EC2 インスタンスにアタッチされた EBS ボリュームの暗号化を有効にする	強く推奨	データセキュリティ	検出

予防と検知以外のControl Towerの機能

　Control Towerを設定すると、SCPとConfig Rules以外にも沢山のサービスの設定をおこないます。ところどころ言及していたOrganizationsの作成はもちろんのこと、組織ユニット（OU）の作成やログやセキュリティ用のAWSアカウント作成まで行います。また、Security Hubを設定したりAWS SSOまで用意します。

　それ以外にも、１アカウント１VPCを徹底させるためか、デフォルトのネットワークの作成等も行います。この辺りの一つ一つの機能を解説すると非常に長くなるので、また日を改めて解説します。予防と検知については、技術書典８で発表した、『AWSの薄い本Ⅱ アカウントセキュリティのベーシックセオリー』で詳しく取り上げています。次回、技術書典９でマルチアカウント管理をテーマに１冊書く予定です。それにてIAM本の３部作は完結となります。お楽しみに〜

booth.pm

AWS認定セキュリティ – 専門知識の試験対策本を書きました

　Twitter等で告知しておりましたが、AWS認定セキュリティ 専門知識の試験対策本を書きました。販売開始は今月末の、2020年7月29日です。

要点整理から攻略する『AWS認定 セキュリティ-専門知識』

書名や価格は暫定版だと思います。
書名・価格が正式なものになっています。

試験対策本の内容

　試験対策本なので、試験要項に沿った形の章立てとなっております。最初の1章で、AWS認定試験の概要と試験勉強の仕方、教材についての説明をしています。2〜6章がメインで出題分野ごとに、対応するサービスとその考え方をまとめています。そして7章でWell-Architectedについては、セキュリティの柱を取り上げています。ここでは、実際にWell-Architectedをダウンロードして読んでもらうという前提を置いたうえで、では対策として実際にどのようなサービスを使うのかを補完する形でまとめています。最後はお約束の問題の解き方と、練習問題です。

1. AWS認定試験の概要
2. IDおよびアクセス管理
3. インフラストラクチャのセキュリティ
4. データ保護
5. ログと監視
6. インシデント対応
7. Well-Architected
8. 問題の解き方

著者について

　今回も会社の同僚と書いています。上野さんは、2020年のAWSのAPN AmbassadorおよびTop EngineersかつALL AWS Certifications Engineerという長い肩書を持ってます。要は、AWSの認定試験12種全部持ってアンバサダーにも選ばれているという実力者です。最近、精力的にJAWSUG等に登壇しているのですが、どんなテーマで話してもどうやって試験に受かるのという質問が一番多くて困っているそうです。AWSの認定試験を受けだして、2年かそこらくらいで全部取ってしまっているのが脱帽です。あと、情報処理試験の高度も、ほとんど持っています。
　もう一人の共著者の小林さんは、情報処理試験の高度をコンプリートしているという世にも珍しい人です。なんだか知らないけど、半年ごとに資格を取っていってあっという間にコンプリートしていました。諸般の事情でAWSの試験はあまり受けていないですが、セキュリティの対策本を書くから取っておいてというと、あっさり試験に合格していました。もちろん、プロも取っています。たぶん、AWS認定の受験を再開したら、あっという間に全部取ってしまうのではと思っています。
　また、過去に一緒に書いたイラスト図解式 この一冊で全部わかるWeb技術の基本のメイン著者でもあります。この本の6割以上は、小林さんが書いていたと思います。私は、2ページほどしか書いていません。この本が発売して３年経ちますが未だに売れ続けていて、今でもカテゴリートップに輝いていることが多々あります。先日もまた増刷して、合計９刷、累計25,000部になっています。技術書の中では、大ベストセラーです。

イラスト図解式 この一冊で全部わかるWeb技術の基本

　ということで、AWSについても試験についてもプロフェッショナルな2人が中心に書き上げています。私は、AWS認定も資格試験もコンプリートしていまあせんが、IAM本とアカウントセキュリティ本を書いていたということで、１＆２章の担当しています。

booth.pm
booth.pm

本書のお勧めポイント

　本書のお勧めポイントとしては、試験対策本として書かれていますがAWSのセキュリティサービスの指南書にもなっているという点です。具体的な設定方法などは範疇外なので書いていませんが、どういう時にどのようなサービスを使えば良いのか、またその理由は何なのかを解るように書いています。この辺り、上野さんが最近JAWSUGに幾つか登壇し話しているような内容です。スライド等を見ていただければ、イメージつくのではないでしょうか？

speakerdeck.com

　後はやっぱり練習問題ですね。私は問題を作るという能力にかけているようですが、二人が作る問題は的確でこんな感じで出てきそうというのが取り揃えられています。最後の２択で迷うような引っ掛け問題も用意されていて芸が細かいなぁと思います。当然、解説の方もしっかり説明していて、どうしてその答えが導出されるのか順を追って解説しています。

感想

　日本初のAWS認定試験のスペシャリティの対策本です。期待しておいてください。日本のセキュリティー専門知識の受験者数と合格者数を大幅に増やして、AWS本国の試験担当の人に、日本はなんでセキュリティのスペシャリティだけ突出して高いのだろうと言わせたいです。みんなで認定セキュリティを合格しましょう！！
　あと執筆していて気がついたのですが、プロの対策本を書くよりスペシャリティの方がテーマがハッキリしていて書きやすいなと思いました。売れ行き好調であれば、別のスペシャリティの対策本を書いても良いかなと思い出しています。あとは、プロ本もいよいよ出てきたので、そのうち私もプロ対策本を書くことに挑戦してみようかとも思います。まぁ時間が限られているので、今の宿題を全部片付けてからですが。。。あと個人的には、やっぱりAWS認定を全部取っておかないとという思いを強くしました。あと３つなので、月１個くらいは取れるように精進します。
　現在、最終校正中で目次がまだ確定していません。確定次第、また順次紹介していきます。Amazonは最近書籍の在庫補充が遅いので、一度品切れになると中々買えません。確実に買いたい場合は今のうちに予約しておいてください。それでは、お楽しみに〜

要点整理から攻略する『AWS認定 セキュリティ-専門知識』

AWS Control Towerの削除方法

　AWS Control Towerは、複数のAWSアカウントを管理するためのサービスです。AWS Organizationsを構築して、傘下のアカウントのセキュリティとガバナンスを、Security HubとSCPを利用しながらガッチリと守り、各アカウントへのログインにAWS SSOを用意したりと至れり尽くせりなサービスです。
　複数のAWSアカウントを監理している方は、非常に興味を持っているのではないでしょうか？今日は、そんなControl Towerの消し方を御紹介します。

Control Towerと関連AWSアカウントの消し方の手順

　とりあえずControl Towerを評価してみたくて、Control Towerを作ってみたものの消し方が難解すぎて四苦八苦する人を散見するようになりました。そんな人のために、主に自分のために記録を残しておきます。Control Towerとそれによって作られたAWSアカウントの消し方は、次のような流れとなります。

1. Control Tower の環境クリーンアップを実施する
2. メンバーアカウントの登録解除
3. 各アカウントの解約

Control Tower の環境クリーンアップを実施する

　さらっと書いていますが、このControl Towerの環境クリーンアップ（消し方）が大変です。公式ドキュメントにわざわざ消し方が用意されています。

廃止プロセスの概要
Landing Zoneの廃止
廃止処理中に削除されないリソース

　まずControl Towerのランディングゾーンを消すためには、AWSサポートに依頼をする必要があります。サポートレベルは無料のベーシックでも大丈夫ですので、「アカウントと費用に関する問い合わせ」からControl Towerの削除依頼を出します。そうすると、担当のチームに引き継がれ1週間以内くらいで準備がされます。これがControl Tower削除の際の1つ目のつまづきです。

　そうすると、Control Towerの設定ページでランディングゾーンの廃止のボタンが出てきます。おどろおどろしい警告を読んで、チェックすると削除プロセスが開始します。これが結構時間がかかり、数時間は見ておきましょう。

　この削除プロセスが終わっても、Control Towerが作った生成物が全て削除される訳ではありません。具体的には、OrganizationsとAWS SSOとS3バケット、傘下のメンバーアカウント（AWSアカウント）が残ります。これらを手動で削除していく必要があります。
docs.aws.amazon.com

　Control Towerだけを消したい場合は、ここまでの作業で大丈夫です。

メンバーアカウントの削除

　Control Towerは、Organizationsを作成時にAuditとLog archiveという名前のAWSアカウントを作成します。

　これらを削除するのですが、AWSアカウントの削除はルートアカウントでしか行なえません。そして、ルートアカウントのメールアドレスは指定したもののパスワードが解りません。これが2つ目のつまづきがあります。実は、Control Towerからアカウント作成時に、自動的に長い桁数のパスワードが設定され、どこに表示されるでもなく破棄されています。なので、正解はパスワード忘れで、パスワードを再発行することです。

　別にパスワード忘れていないのにとイラッとしますが細かい事は水に流しましょう。パスワードの設定の際に、どうせすぐ消すからと簡単なパスワードを設定しようとすると、１文字以上の数字・大文字・記号を求められて更にイラッとします。
　無事ログインができると、後はマイアカウントからアカウントのアカウント設定から解約するだけです。AuditとLog archiveのアカウントを解約すると、次のような状態になります。

　自動生成されたAWSアカウント以外に、他に新規でアカウントを作っている場合はそれも削除しましょう。Organizationsに紐づくアカウントが全てなくなっている。或いは停止状態すると、Control Towerで作ったアカウントも削除できるようになります。マスターアカウントであるControl Towerを作ったアカウントに、ルートアカウントでログインして削除しましょう。

まとめ

　Control Towerを廃止しない状態でも、メンバーアカウントを削除することは可能だと思います。今回は、AWSの公式の手順に従って削除してみました。またControl Towerだけ削除したいケースもあると思いますので、その際は、『Control Tower の環境クリーンアップを実施する』のみを実行してください。
　そもそもControl Towerとはなんぞやと気になっている人がいるとは思うので、おいおい解説します。また、『AWSの薄い本Ⅱ アカウントセキュリティのベーシックセオリー』という本にも概要を説明していますので、興味があれば是非読んでみてください。

booth.pm