クラウド管理を自動化する4つのフェーズ

セキュリティ担当者のクラウド自動化の歩み

カンファレンスで私を見かけたら、「クラウドセキュリティはアーキテクチャに始まり、自動化に終わる」と話しているのを耳にする可能性が高いでしょう。そしてすぐに、データセンターの契約が切れて照明を落とすまでの間、無骨なリフト＆シフトの現実に追われているときでさえ、クラウドネイティブな考え方を取り入れることがいかに重要かを続けて述べます。気の利いた一言ではありますが、私が「肉とじゃがいも」的な（ファイアウォールとパッチ管理中心の）セキュリティ担当者から、アーキテクチャと自動化を扱うクラウドネイティブな人間へとどう変わったのかは、まったく伝えていません。高みから説くよりも、私自身の歩みと、その過程で得た技術的な気づきを述べるほうが有用だと考えています。あなたがセキュリティ担当者であれ、クラウド向けにセキュリティ担当者のスキルを引き上げようとしている方であれ、おそらく非常に似た道をたどることになるはずです。

フェーズ1：構成の自動化

私の場合、すべては約9年前、Cloud Security Alliance の最初のトレーニングプログラムを構築するよう依頼されたときに始まりました。早い段階で、世界中どこでも実行でき、「開発者」から「書類仕事中心の監査人」まで幅広いスキルを持つ受講者と講師の双方が使える、再現性のあるラボが必要だと気づきました。当時、Amazon Web Services はまだ IAM を本格的に展開しておらず、VPC はプライベートネットワーク専用でした。そして Infrastructure as Code のような概念は、ようやく実現可能になり始めたところでした。

そこで私は、数千人の受講者向けに、クラウド上でハンズオンのアプリケーションスタックのラボをどう構築するかを考えることになりました。一貫性を保ちながら、*かつ* AWS が技術を進化させるのに合わせて更新できる形で。当時、独自の AMI を作るのはまだ手間のかかる作業でしたが、そこで `cloud-init` という素晴らしい仕組みを知りました。S3 バケットに置いておける単純なスクリプトで、受講者がインスタンスの User Data フィールドに貼り付けるだけの2行があれば、起動時にインスタンスを必要どおりに構成してくれます。ソフトウェアの更新で不具合が起きても、公開している URL のスクリプトを更新するだけで、新しいインスタンスはすべて新しい構成を使うようになります。まさに魔法です。これは稼働中のものへのパッチ適用には役立ちませんでしたが、新しい AMI を更新して公開するよりもはるかに容易に、良好な初回起動体験を維持できました。そして、評判を顧みない無謀さで、後のバージョンの1つは今も S3 でご覧いただけます。

最初のステップは `cloud-init` でした。今はもう使っていませんが、コピー＆ペーストとホストされた1つのファイルだけで、サーバー全体をスクリプト化して動かせるというのは目を見張るものでした。

フェーズ2：ワークフローの自動化

しかし次のステップは、はるかに大きな影響がありました。数年にわたってハンズオントレーニングを実施し、自分自身のワークロードを構築したのち、Software Defined Security という考え方を試し始めました。目の前には、耳元で「呼び出して」とささやくクラウド API の宝庫が広がっていました。私は事例を探し始めましたが、見つかったのは…何もありませんでした。Security Monkey すら、まだ公開されていなかったのです。

Black Hat セキュリティカンファレンスでの講義を控えていた私は、それを口実に Ruby と（Ruby SDK 経由で）AWS API を学ぶことにしました。最終的に3つのデモを作成しました。

• インスタンスを隔離し、そのメタデータをすべて分析し、AWS IAM を使ってロックダウンし、すべてのストレージをイメージ化し、アタッチされたスナップショットをすぐ分析できるフォレンジック分析サーバーを起動するインシデントレスポンスアプリケーション。以前は30分かかっていた作業を3秒で実行しました。
• AWS と Chef に接続し、Chef を実行していないすべてのインスタンス（「管理外」のサーバー）を特定する小さなアプリ。従来のデータセンターでは数週間かかりかねないプロセスです。
• Qualys スキャナー向けにセキュリティグループを開放し、スキャンを起動し、完了時にセキュリティグループを閉じるもう1つのアプリ。

それまで Ruby でコーディングしたことがなかったため、3つすべてを動かすまでに、パートタイムの作業で約2か月かかりました。どれも非常に単純なものでしたが、貴重な教訓をいくつか得ました。

• 認証情報の管理は極めて重要であり、同時にコードを共有して他者に環境を正しく構成してもらうことを難しくしていました。構成ファイルから読み込む方式は…厄介でした。特に、どのリージョンのどのセキュリティグループを隔離用グループとして使うか、といった設定については。
• ローカル環境の Ruby では問題なく動作しましたが、AWS のインスタンス上でコードを実行するとサービス制限を超えてしまい、遅延タイマーを挿入せざるを得ませんでした。API のサービス制限は味方ではありません。
• これらはいずれも完全に静的なものでした。デモとしては洗練されていても、結局はデスクトップやインスタンスから手動でコードを実行するだけでした。その点は、時の経過に耐えられていません。

これらを「SecuritySquirrel」としてまとめました。2014年版は GitHubでご覧いただけます。信じられないかもしれませんが、これらは公開前の数年間に使っていたオリジナルですらありません。

フェーズ3：クラウドそのものの自動化

AWS が CloudWatch の Rules をリリースしたとき、私は翌週の土曜の朝に約2時間で Python コードを一気に書き上げ、セキュリティグループの変更を10〜15秒以内に元に戻せるようにしました。タグ、VPC、変更のリクエスト元に基づいて防御の範囲を絞るフィルターも含めています。コードと手順はダウンロードいただけます。Ruby のコードとは違い、3年前のクラウドコードとしては今もかなり良好に動作します。

その最初のデモ以来、Lambda で動作するイベント駆動型の自動化処理のライブラリを構築してきました。その一部はダウンロードいただけます。そのパッケージで私のお気に入りは `identify_internet_facing_servers.py` です。デモ用に、Amazon Dash ボタンの IoT 版をクリックすると起動するようリンクさせています。そのとおり、私は実物の Easy ボタンをポケットに入れて持ち歩いています。このコードはポート22がインターネットに開放されているインスタンスを見つけ出し、ボタンをダブルクリックすればルールを取り消して、すべてが安全な状態になるとスマートフォンにテキストメッセージが届きます。

ここで得た重要な教訓は、予想外のものでした。これらのイベント駆動型の自動化がホストベースのワークフローを置き換えたということではなく、両者が異なる目的を果たしていたということです。作業をより速く進めるためのワークフローの構築から、バックグラウンドで安全性を保つためのガードレールの構築へと、自分が移行していたことに気づきました。どちらにも計り知れない価値があります。

フェーズ4：すべての自動化

直近の取り組みは、Jenkins と Infrastructure as Code（主に CloudFormation）を使ってセキュリティを強化することです。この組み合わせにより、インフラストラクチャとアプリケーション自体にセキュリティを自動的に組み込み、外部ツールへの依存を減らせます。

たとえば、シンプルな認証情報スキャナーを公開しました。Jenkins 上で実行し、ビルドを開始する前に保存されたアクセスキーを検出するものです。後から探し出そうとする必要はありません。その後、Jenkins 上で任意の評価ツールをほぼ何でも実行できるテストハーネスをいくつか作成し、ネットワークスキャンなどのセキュリティテストに失敗した場合はビルドを失敗させるようにしました（ヒント：スクリプトから0以外の終了コードを返すと、Jenkins はビルドを失敗させます）。

話を戻すと、現在ではトレーニングクラスを CloudFormation テンプレートで運用し、アプリケーションスタックの全要素を構築することで、受講者はセキュリティの追加に集中できるようになっています。一貫性のあるトレーニングサーバーの構築から、一貫性のあるトレーニング環境の構築へと進み、カスタム AMI を数分で…グローバルに…ごくわずかな労力で更新でき、すべてのソフトウェアがインストール済みで最終構成を待つだけの状態になりました。

私のクラウドの歩みは約9年前に始まり、自動化の歩みもほぼ同時期に始まりました。最初は何かを構築してから部分的に自動化しようとしていましたが、今では自動化を前提として着手します。初期の取り組みは運用に関するものでしたが、近年はほぼすべてがセキュリティに焦点を当てています。運用上のオーバーヘッドを溶かし去り、思考のセキュリティに関わる部分を、それが最も得意とすることに集中させるためです。その過程で、すべての自動化が同じ価値を持つわけではないことも学びました。ガードレール、ワークフロー、クロスプラットフォームのオーケストレーション、Infrastructure as Code、パイプラインの自動化には、それぞれ適した領域があります。これらはいずれも、今やほとんど想像を超えるセキュリティ上の恩恵をもたらしますが、ドキュメントが不十分な API の解析だけで1週間を失いかねない、まだ非常に初期の段階にあります。

セキュリティに携わっているなら、コードの腕を磨くときです。開発や運用に携わっているなら、セキュリティの腕を磨くときです。最大の教訓は、傘としてのセキュリティの時代は終わり、組織の織り目に組み込まれたセキュリティの時代が到来したということだからです。