プログラマでありたい

おっさんになっても、プログラマでありつづけたい

Fin-JAWS 第14回で、AWS認定セキュリティ専門知識を基軸にAWSのセキュリティについて話しました

 8月13日に開催されたFin-JAWS 第14回 Fin人類育成計画で、論理登壇しました。全体のテーマは人材育成ということで、AWS認定試験の対策本の著者たちが集まってそれぞれ話しています。私は、セキュリティ専門知識の対策本を出した縁で、AWSのセキュリティの考え方を軸に話しました。

fin-jaws.connpass.com

登壇資料とTogetterまとめ

 当日の登壇資料は、これです。

speakerdeck.com

 当日のTwitterのまとめです。かなり活発に意見が飛び交いまして、最後には#finjawsのハッシュタグがトレンド入りしていました。

togetter.com

AWSのセキュリティの考え方

 資料中に書いていますが、当日話したことをダイジェストでお伝えします。

巨人の肩に乗る

 今やセキュリティ対策として検討する必用がある領域は、非常に多岐に渡っています。何の対策が必用か、自分で考えるのは現実的ではなくなっています。そこで、先人たちが考えたフレームワークに乗っかかるというのは非常に有効です。いわゆる巨人の肩に乗るということですね。

f:id:dkfj:20200820084747p:plain

 AWSのセキュリティ分野であれば、NISTのサイバーセキュリティフレームワークとAWS Well−Architectedフレームワークをまず読むことをおすすめします。

NIST サイバーセキュリティフレームワーク コア(IPA公開版)
AWS Well-Architected フレームワーク

 この2つを読み比べると解るのですが、どちらも結構似たことを言っています。それもそのはずで、AWS Well-Architectedのセキュリティの柱はNIST サイバーセキュリティフレームワークを下敷きにしている部分も多々あります。また既にWell-Architectedフレームワーク読んだよという方も、もう一度読んで見ることをお勧めします。2020年3月と7月に改訂されています。フレームワークもどんどん進化しているということですね。

 NIST サイバーセキュリティフレームワークの解説については、次の記事がお勧めです。

www.secure-sketch.com

フレームワークを当てはめる

 フレームワークでセキュリティ対策の概要を知ったら、次は実際のシステムにどのように当てはめればよいのかを考えてみましょう。その際のお勧めは、要素・構成を抽出して、同じシステムでも目的別・レイヤー別・アーキテクチャ別などいろいろな観点から構成を考えてみるのがよいです。

f:id:dkfj:20200820085748p:plain

f:id:dkfj:20200820085803p:plain

f:id:dkfj:20200820085815p:plain

 実は上記の図は全て、私が書いた技術同人誌である『AWSの薄い本Ⅱ アカウントセキュリティのベーシックセオリー』からの引用です。当日話した内容をテキストベースで詳しく説明しているので、もし興味がありましたらBOOTHで見てください。2章までの無料版を公開しています。

booth.pm

伴走者を見つける

 これも持論ですが、この手の対策は机上でドキュメント読むだけで身につけるのは中々難しいです。実際に自分で設定して運用してみると、セキュリティーフレームワークが言わんとしていた事が理解できるようになってきます。で、実際に対策しようと、最初の取り掛かりが非常に大変です。なぜならばフレームワーク読んだとしても、実際に手を動かそうとした瞬間に何からすれば良いのか全く解らなくて途方にくれるからです。
 そんな際にお勧めは、最初は伴走者をつけることです。スタート時点で自分の少し前で走ってくれる伴走者がいると、走り出しが非常にスムーズになります。最初にすべきこと、次にすべきことといった優先順位の付け方の相談ができるだけで、心理的な負荷も小さいです。そして、気がついたら自走しているという形が理想的ですね。
 少し宣伝が入りますが、最近AWSのセキュリティ相談に関する案件が増えていることもあり、セキュリティ支援のサービスも開始しています。どういったアプローチで対策するかや、定番の対策方法についてはテンプレート化して提供もしています。も興味があれば、お気軽にお問い合わせください。

www.nri-net.com

まとめ

 ということで、AWSのセキュリティをどのような観点で考えて対策していくのかということの紹介でした。何から始めればよいか途方にくれている人の一助となれればと思っています。あと今月は、8/25にJAWS-UG朝会、8/28にSecurity-JAWS と立て続けに登壇します。朝会の方はCloudFormation StackSets × Organizations、Security-JAWSは試験対策寄りの話しをする予定です。お時間の都合が付けば、ぜひご参加ください。

jawsug-asa.connpass.com

s-jaws.doorkeeper.jp


AWSのAutoScalingの整理 猶予期間・ウォームアップ・終了ポリシー編

 基本に立ち返ろうということで、AWSのAutoScalingの仕様の確認です。前回は、スケーリングポリシーを中心に確認でした。今回は、起動や終了に関わる仕様ということで、猶予期間・ウォームアップ・クールダウン・終了ポリシーなどの解説になります。

前回
AWSのAutoScalingの整理 スケーリングポリシー編 - プログラマでありたい

ヘルスチェックと猶予期間



 まず最初にヘルスチェックと猶予期間です。ヘルスチェックは、AutoScalingの管理対象下のインスタンスの動作をチェックして、異常が認められた場合は新しいインスタンスと置き換えられます。

Auto Scaling インスタンスのヘルスステータスは、正常または異常のどちらかです。Auto Scaling グループ内のすべてのインスタンスは正常な状態で起動されます。インスタンスに異常があるという通知を Amazon EC2 Auto Scaling が受け取らない限り、インスタンスは正常であると見なされます。この通知は、Amazon EC2、Elastic Load Balancing (ELB)、カスタムヘルスチェックのうち 1 つ以上のソースから送られる可能性があります。

Amazon EC2 Auto Scaling がインスタンスを異常ありとマークすると、置き換えがスケジュールされます。インスタンスを置き換えない場合は、個々の Auto Scaling グループに対するヘルスチェックプロセスを停止できます。

Auto Scaling インスタンスのヘルスチェック - Amazon EC2 Auto Scaling (日本語)

 このヘルスチェックの挙動を理解するために重要になるのが、ヘルスチェック猶予期間です。英語では、Health Check Grace Periodです。AutoScalingが発動してインスタンスが起動されても、インスタンスの起動時間やインスタンス内のプロセスの起動時間があるために、すぐにそのインスタンスが利用可能な状態になる訳ではありません。その間にヘルスチェックでエラーが出続けると困るので、一定期間ヘルスチェックをしないという猶予期間があります。画面コンソールから作った場合の、猶予期間はデフォルトで300秒(5分)です。が、CLIやSDKから作った場合は、なんと0秒です。この辺の差異がある経緯、ちょっと気になりますね。

f:id:dkfj:20200810154503p:plain


 ヘルスチェックの猶予期間の設定画面をみると、EC2ELBの2つのヘルスチェックがあることに気が付きます。この違いは何なのか、それぞれ見てみましょう。

Amazon EC2 ステータスチェック

 まずEC2の方です。こちらは、正式名称がAmazon EC2 ステータスチェックです。その名の通り、EC2インスタンス単体としてのヘルスチェックを行います。AutoScalingのデフォルトのチェックは、こちらです。

Elastic Load Balancing (ELB) ヘルスチェック

 Elastic Load Balancing (ELB) ヘルスチェックは、ELBが提供するテストに基づいて判断されます。対象となるものは、ALBとNLBのターゲットグループならびにCLBです。ヘルスチェックの方法は、ELBの種類によって異なります。ALBの場合はアプリケーションレイヤー (HTTP および HTTPS) のヘルスチェックをサポートし、NLBとCLBの場合は、アプリケーションレイヤー (HTTP/HTTPS) とTCPの両方のヘルスチェックをサポートします。インスタンスは正常だけど、ELBから利用するプロセスが異常という場合に、素早く対処したい場合はELBヘルスチェックを利用します。
 ELBのヘルスチェックでややこしいのは、ヘルスチェック猶予期間はあくまでAuto Scalingの中だけで完結していることです。つまり、ELBからのヘルスチェックは猶予期間内であってもUnHealthyを返します。アラートがならないようにヘルスチェックをするには、この辺を考える必用があります。

 クラスメソッドさんのブログでも同じテーマで課題提起があり、ELB側ではなくAuto Scaling Group側のGroupTerminatingInstancesがお勧めとのことです。

ELB配下でAuto Scalingを構成する場合には、ELB側のUnHealthyHostCountを利用するのではなく、Auto Scaling Groupが持っているGroupTerminatingInstancesメトリクスを利用した監視がオススメとのことです。

EC2 Auto Scaling グループの「ヘルスチェックの猶予期間」を正しく理解する | Developers.IO

スケーリングクールダウンとウォームアップ


 ヘルスチェックの猶予期間を理解したのでAutoScalingについては完璧かと思いきや、AutoScalingにはクールダウンとウォームアップという概念があります。こちらも理解しておきましょう。

クールダウン

まずはクールダウンです。正式名称は、スケーリングクールダウンというようです。これはAutoScalingが発動した直後に追加でインスタンスの増減がなされるのを防ぐための設定です。猶予期間と混同されがちですが、猶予期間はヘルスチェックの猶予であり、クールダウンはインスタンスの増減のアクションの発動に対してのパラメータとなります。

f:id:dkfj:20200810184407p:plain


 ちなみにAWSの説明では、古い設定であり現在ではデフォルトの設定のまま調整しないで済むとバッサリと切り捨てられています。

スケーリングアクティビティが完了してから別のアクティビティが開始されるまでの時間を変更します。時間の長さは、インスタンスのウォームアップ期間、またはその他のアプリケーションニーズに基づいて設定できます。これは古い設定であり、ほとんどの場合において、デフォルトの 300 秒のままとすることができます。クールダウンオプションは、ターゲット追跡スケーリングポリシー、ステップスケーリングポリシー、またはスケジュールされたスケーリングではサポートされていません。

 切り捨てられている理由としては、クールダウンは主として簡易スケーリングに対するパラメータとして動いているためです。ステップスケーリングの場合、メトリクスに対して複数の閾値が指定できます。そのためスケーリング動作中に、別の閾値に達した場合にはクールダウンと関係なく反応するようになっています。一方で50%で1台追加で60%で2台追加と設定している場合、50%に反応して1台追加中に60%に達し更に2台追加となると過剰に追加しすぎとなる場合があります。それを抑止するために、ウォームアップという概念があります。

ウォームアップ

 ウォームアップは前述のとおり、ほぼステップスケーリングで差分でインスタンスを追加するために追加された機能です。事実、ステップスケーリングの機能が追加された時に、パラメーターとして登場しています。動作のポイントは2つです。CPUの利用率が50%の時に1台追加、70%の時に2台追加というポリシーが設定された場合を例に解説します。

  • (インスタンス追加され)ウォームアップ期間中には、そのアラームでのインスタンス追加はされない
  • ウォームアップ期間中に次のアラート(70%)が発動した場合、差分の台数が追加される

f:id:dkfj:20200810231420p:plain

ウォームアップは、ステップスケーリングとターゲット追跡スケーリングポリシーに対応しています。

その他のAutoScalingのオプション


 猶予期間とクールダウン、ウォームアップを理解できれば、AutoScalingのオプションについて、ほぼ理解していると言えるのではないでしょうか。ただ、上記以外にも、まだ幾つかオプションがあります。代表的なのがライフサイクルフックと終了ポリシーです。せっかくなので、この2つについても見ていきましょう。

ライフサイクルフック

 ライフサイクルフックは、Auto Scalingグループによるインスタンスの起動時または削除時にインスタンスを一時停止してカスタムアクションを実行する機能です。例えば、起動時にデータを取得してきたり、削除時にログやデータの退避の処理を追加するといった用途で使えます。待機時間はデフォルトで1時間、最大で48時間まで設定できます。ただ48時間必用なケースは、どうしても思い浮かびません。

https://docs.aws.amazon.com/ja_jp/autoscaling/ec2/userguide/images/lifecycle_hooks.png

終了ポリシー

 負荷に応じてインスタンスを増やすのをスケールアウトと言います。これに対して、負荷が下がってインスタンスを減らす場合はスケールインといいます。さてAutoScalingでは、スケールインの際に、どのインスタンスを削除するのでしょうか?これを決めるのが、終了ポリシーです。デフォルトの終了ポリシーでは、インスタンスがアベイラビリティーゾーンに均等に配分されるように削除します。2つのAZで2台・3台とインスタンスがある場合、3台あるAZのインスタンスを一つ削除させてAZ間で均等にさせるというような動作になります。それ以外にも、

終了ポリシー 概要
OldestInstance 最も古いインスタンスを削除
NewestInstance 最も新しいインスタンスを削除
OldestLaunchConfiguration 最も古い起動設定のインスタンスを削除
ClosestToNextInstanceHour 次の課金時間に最も近いインスタンスを削除
Default
OldestLaunchTemplate 最も古い起動テンプレートを使用するインスタンスを削除
AllocationStrategy スポットまたはオンデマンドなどのインスタンスタイプの配分戦略に沿って削除

ClosestToNextInstanceHourなんかは、出た当初は素敵と思ったのですが、今はEC2のインスタンスの課金単位時間が1時間から1秒に変わりほぼ意味がなくなっていそうです。今だと、どういった挙動になるのは、どこかで実験してみます。1時間という前提を残して動くのではと予想しています。

まとめ



 前後2回に渡って整理してきたEc2 AutoScalingの仕様の確認はいかがでしたでしょうか?普段使わない設定も多く、知らない事も多かったのではないでしょうか?AWSの認定試験は、ケースごとにどのような設定をすれば良いのかということを問われます。そのためには、網羅的に仕様を把握しておく必用があり、AutoScalingは特に重要なポイントです。ELBとAutoScalingは一緒に設定することが多く、どれがどちらの仕様か混同して覚えてしまうことが多いです。一度、AutoScalingとELBを別々に学ぶというのは有効だと思います。
 次回は、ELBを整理してみようと思います。

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

ステップスケーリング

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

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

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

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

f:id:dkfj:20200808110009p:plain

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

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

f:id:dkfj:20200808113306p:plain

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


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

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


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

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


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

f:id:dkfj:20200809094808p:plain

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

f:id:dkfj:20200809100845p:plain

AWS Auto ScalingとAmazon EC2 Auto Scaling


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

f:id:dkfj:20200808221245p:plain

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

f:id:dkfj:20200809101725p:plain

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

f:id:dkfj:20200809101744p:plain

 こういった感じで、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認定 セキュリティ専門知識の対策本の書名・目次と書影

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

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

書籍の内容について

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

fu3ak1.hatenablog.com


blog.takuros.net

表紙について

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

f:id:dkfj:20200719003858j:plain

目次

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

第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のより良い利用方法を習得している人が増えることに寄与すると信じています。
 ちょっと他の宿題を片付けたら、他のスペシャリティやプロフェッショナルの対策本についても検討してみようかなと思います。

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)というポリシーを作って、グループやロールに追加するのが良いのではと思います。そうすることで、権限を制御するポリシーと有効期限を制御するポリシーを分離でき、権限ポリシーのパーツ化が図れます。図にすると、こんな感じですかね。

f:id:dkfj:20200707123355p:plain

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

f:id:dkfj:20200707123546p:plain

 まぁこんな感じで使えるかなぁと思ったネタです。不要な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の権限を持っていたとしても、予め許可した範囲しか権限が有効にならなくなります。次の図のように積集合ですね。

f:id:dkfj:20200706050355p:plain

 この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(関所)と読んでいます。ガードレールは安全柵ですね。何度かお見せしてたかもしれませんが、関所とガードレールの違いを表した図になります。

f:id:dkfj:20200703081137p:plain

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

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

f:id:dkfj:20200703081553p:plain

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まで用意します。

f:id:dkfj:20200703081608p:plain

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

booth.pm