しまかぜメモ

Masanori Yamaguchi の雑なメモ

AWS SecurityHubで開発環境のセキュリティコンプライアンスを可視化する

TL;DR

  • 開発環境ってみんなでいじるよね
  • AWSの知識も人それぞれ、セキュリティの知識も同じく
  • ガチガチすぎると作業効率が落ちる
  • ガチガチに固めることはせず、はみ出した状況を可視化して対策しよう
AWS Security Hubとは(2020/2/11 現在)
  • 2019年6月24日 一般提供開始(東京リージョンでも利用可能)
  • AWSアカウントのセキュリティアラート、コンプライアンス状況を可視化
  • Amazon GuardDuty、Amazon Inspector、Amazon Macieの結果も Security Hubからまとめて確認可能
  • 3rd パーティ製品のセキュリティアラート、スキャン結果にも対応
  • Insightで独自のダッシュボードを作成可能
  • 1000までのアカウントをまとめて可視化できる
  • CIS AWS Foundation Benchmarkに対して環境が準拠しているかチェックできる

詳細は公式のサービスページを確認。 https://aws.amazon.com/jp/security-hub/

やりたいこと

各開発プロジェクト用の開発環境AWSアカウントのセキュリティコンプライアンス・セキュリティリスクを可視化・管理したい。

開発環境の特性（組織や環境によって差はある）
  • プロジェクト立ち上げと新規構築の頻度がほぼ同一
  • 開発環境だから本番環境よりもセキュアでなくても良いということは 許されない
  • 開発速度、スケジュールも重要(ガチガチのルールを適用するのは難しい)
  • チーム、ロケーションにより環境に対する制約も変わる
  • ベースライン、ルール、教育はあるものの全ての開発エンジニアが AWSのプロフェッショナルという訳ではない
  • 回避できず低減、受容などの対応を選択することもある
AWS SecurityHubを使うことで実現出来たところ
  • アラートの正規化が不要
  • 複数アカウントのセキュリティアラートを可視化・集中管理できる
    • 特に定期的なセキュリティチェックはかなり楽になる
  • カスタムアクションとの組み合わせで対象アカウントにログインせず修復することができる
    • 実際、そこまではやっていない

特に複数アカウントをまとめて管理できるところは嬉しい。 今回適用した各開発アカウントは全てOrganizationに入れているので導入も難しくなかった。

AWS SecurityHubにがんばってほしいところ
  • カスタムアクションの自動実行
  • CIS AWS Foundation以外の対応
  • Insightでパイチャートなど他のグラフ描画への対応
  • Control Tower との連携

アカウント作るときに別の手段で自動化しちゃえばよいのだけど、SecurityHub有効した状態でアカウント作れると作業が楽かなー、と。

また、しばらく運用して、どこかで話して見ようと思います。

EC2 Image Builderのエラーパターン

12月12日にFinJAWSのreCapイベントLTしてきました。内容をブログにも書いておきます。

EC2 Image Builder

re:Invent 2019で発表された、EC2のマシンイメージであるAMIを構成する為の下処理(パッケージインストール、設定、テストなど)を自動化でき、かつ自動化するためにはコードが必要なので、AMIをコードで管理出来るというメリットをもつサービス。
今までHashiCorpのPackerとAnsibleやServerspecなどを組み合わせて実現してきたことをAWSサービス内で完結できるようになった。
ちなみに、僕は触っていはいるけど、まだPacker使ってます。もう少し触ってみたり、周りの人達の情報ももらいながら、移行するか考えたいと思います。

エラーパターン

EC2 Image Builderは、その名の通りビルドジョブを走らせます。ということは、ビルドジョブでエラーも発生するということです。
更にエラーが発生するということはエラー解析が必要になるということですね。
遊びでいくつかエラーを発生してみましたので、その時のエラーメッセージなどを参考に記載していきます。

AutoScaling Groupを用意せず(削除して)ビルドパイプラインを実行する

EC2 Image Builderは、構成要件としてAutoScalint Groupを必要とします。AutoScaling Groupはビルドジョブ実行時に作成されます。
作成されたがAutoScaling Group存在しない場合は、構成要件を満たせないため、ビルドジョブでエラーになります。
基本的に発生しないエラーですが、共有環境で誰かが誤って消してしまった場合、などですかね。

f:id:kinunori:20200518222821p:plain

インターネットからパッケージをダウンロードするジョブに対して、IGWやNATが存在しないサブネットでビルドさせてみる

10分ほどビルドジョブが動作したあと、タイムアウトで死にます。なお、ログ出力先のS3にはログが出力されませんでした。
画像の塗りつぶし部分は環境によって変わる部分です。

f:id:kinunori:20200518223201p:plain

ビルドジョブ実行中に実行対象のEC2インスタンスを終了させてみる

インスタンスは終了したものの、ビルドジョブが走り続けます。最終的にはタイムアウトで終了します。
EC2 Image Builderのジョブは途中終了できないため、ジョブの間違いに気づいたらEC2インスタンスを終了することで途中終了できるということですね。（料金は、EC2の処理実行時間で課金される）

f:id:kinunori:20200518223445p:plain

この手のサービスに関しては事前にテストが難しく、静的構文解析実施後に実際にビルドジョブは実行することがテストになりがちです。
エラー解析の知識が必要になるため、可能な限り利用者で共有していけると、みんな幸せになれるかも知れませんね。

AWSを使う場合にALB+HTTP/2で気をつけないといけない話

11月7日にFinJAWSでLTしてきましたので、その時の内容をブログ化でも共有します。

TL;DR
  • (11月7日現在)HTTP/2を有効にしてもAWS内の通信は全てHTTP/2ではない
  • ALB -> EC2 間はHTTP/1.1で通信される
  • ブラウザからエラーで弾かれるケースもある
  • 回避方法
構成

構成図に書いている各サービスのHTTP/2を有効化しても全てがHTTP/2で通信されるわけではない。 f:id:kinunori:20200518215748p:plain

実際は、ALB->EC2間はHTTP/1.1で通信される。（アクセスログから確認） f:id:kinunori:20200518215753p:plain

影響

上記構成において、EC2上で構成されるWebサーバのHTTP/2を有効化していると、HTTPレスポンスヘッダにはUpdateヘッダが付与され、HTTP/2の通信を推奨されるレスポンスが返答される。（しかし、ブラウザはHTTP/2で通信をしている） 特定のブラウザでは、このレスポンスの解釈に問題があるのか、特定端末で特定のブラウザはエラー返却されWebコンテンツが表示されないケースがあった。

下記のChromeのデバッグでは、HTTPレスポンスに対し、Updateヘッダが付与されていることが確認できる。

f:id:kinunori:20200518220407p:plain
ChromeのデバッグよりHTTPレスポンスを表示

この状況において、iOSのChromeでは最終的にエラー画面を返却する。

f:id:kinunori:20200518220623p:plain
iOSのChrome

回避方法
  • CloudFrontにてHTTP/2を無効化する
    • この方法は解決可能であるが、そもそもHTTP/2への対応を無効化するものであり、回避策としては有用ではない。
  • WebサーバのHTTP/2モジュールを無効化する
    • WebサーバのHTTP/2モジュールが有効化されている場合、より効率的なプロトコルであるHTTP/2を推奨する。この動きがUpgradeヘッダであるため、WebサーバのHTTP/2モジュールを無効化することでUpgradeヘッダ付与は回避できる。
    • つまり、ALBまではHTTP/2通信が行われる。重要なポイントはCDNであるCloudFrontとブラウザ間はHTTP/2で通信されるため、キャッシュ済みコンテンツはより効率的なプロトコルで通信されるという点である。

ALBからWebサーバもHTTP/2で通信してくれればよいのだけど。