Snykの チーフアーキテクト、 Josh Stellaが 先日、 クラウドセキュリティに 関する ウェビナーを 開催しました。 Stellaは、 クラウドセキュリティと コンプライアンスを 手が ける 企業 Fugue の 共同創業者兼CEOであり、 同社は Snykに 買収されました 。 Fugueの 機能を 活用し、 Snykは 開発者ファーストの セキュリティプラットフォームを クラウドセキュリティ分野へと 拡大します。
この 講演で Stellaは、 あらゆる クラウド侵害に 欠けている ストーリー、 つまり 攻撃者が クラウド上で、 どのように、 いつ、 どこで 活動するのかに ついて 解説しました。 また、 現代の 攻撃から クラウドリソースを 守る ための 方法論も 紹介しました。
この ブログ記事では、 講演で 紹介された 重要な 知見を いくつか 取り上げます。
クラウドがセキュリティをどう変えたのか まず、 クラウドコンピューティングが セキュリティの あり方を どのように 変えたのかを 理解する ことが 重要です。 かつて データセンターは 比較的 隔離された ハードウェアベースの 環境だった ため、 境界の 防御に 重点を 置くことが 効果的でした。 一方、 現在の クラウドベースの インフラは ソフトウェアに よって 定義されます。 特定の クラウドプロバイダーを 利用する すべての 顧客が、 同じ ハードウェアを 共有している ためです。
ソフトウェア定義型クラウドの 利点は、 柔軟性が 高く、 プログラムで 制御できる ことです。 その ため、 企業は クラウドセキュリティを 含むさまざまな 機能を 自動化できます。 しかし、 この 柔軟性には 複雑さも 伴います。 最新の クラウド環境は 数十万もの コンポーネントで 構成され、 クラウドプロバイダーは 何百もの サービスを 提供している ためです。
課題は、 こうした コンポーネントや サービスの 設定を、 開発者が Infrastructure as Codeを 使って 担う ケースが 増えている ことです。 その 結果、 開発チームには クラウドセキュリティに 関する 責任も さらに 求められるようになっています。
攻撃者の手口も変化している クラウドは、 攻撃者の 活動方法にも 影響を 与えています。 クラウド以前の 時代、 ハッカーは 標的を 選び、 脆弱性を 探して、 時間を かけて 計画的に 攻撃を 仕掛けていました。 現在の ハッカーは、 自動化ツールを 使って 脆弱性を 探し、 標的を 選ぶと、 すぐに 攻撃を 実行します。
つまり、 隠す ことで セキュリティを 確保する ことは できません。 公開されている IPアドレスや DNSは、 公開されてから 数分 以内に スキャンされます。 ハッカーの 標的に なる 可能性が 生じるまで、 何時間も 何日も 待ってくれるわけではありません。
大規模な クラウド侵害に 関する 報道の 多くは、 侵害の 原因が 単一の 脆弱性や 設定ミスに あるかのように 伝えており、 実態を 誤解させる ことがあります。 実際には、 その 多くは コントロールプレーンを 保護できていない システム設計の 不備が 原因です。 攻撃者は、 設定に 不備の ある 単一の クラウドサーバーを 通じて 最初に システムへ 侵入する ことがありますが、 その後、 システム内を 横方向に 移動し、 価値の 高い データを 探して 持ち出そうとします。
クラウドセキュリティの5つの基本 従来の データセンターでは 境界の 防御が 有効でしたが、 現在の クラウド環境で 攻撃者を 防ぐには、 それだけでは 不十分です。 Stellaに よると、 クラウドセキュリティを 継続的に 向上させる 好循環を 生み出す、 5つの 基本が あります。
1. 環境を把握する クラウドシステムを 攻撃する 場合も 保護する 場合も、 環境を 把握する ことが 欠かせません。 たとえば、 特定の クラウド環境に おいて 脆弱性が 実際に どのような 形で 現れるのかを 知る ことは、 クラウドセキュリティの リスクを 最小限に 抑える うえで 非常に 重要です。
2. 予防とセキュアな設計 攻撃者の 主な 侵入口の 一つが 設定ミス である ため、 Infrastructure as Codeや CI/CDパイプラインの 開発時に、 設定ミスを 検出して 修正する ことが 重要です。 また、 設計段階から セキュアな クラウドアーキテクチャを 検討しておけば、 攻撃者が 境界を 突破した 場合でも、 システム内で 横方向に 移動するのを 防ぎやすくなります。
3. 開発者を支援する 開発者は トレーニングや 認定資格を 通じて セキュアな 設計を 学べますが、 クラウドセキュリティの ベストプラクティスを 共有する 最善の 方法は、 自動化と ツールの 活用です。 IaCセキュリティツール を 使えば、 開発者は 既存の DevOpsワークフローの 中で、 実行に つながる セキュリティガイダンスを 得られます。
4. ポリシーをコード化する ポリシー・アズ・コードとは、 Infrastructure as Codeや 稼働中の クラウド環境に おいて、 安全かどうかを 判定できる ソフトウェアです。 つまり、 ポリシー・アズ・コードに よって、 セキュリティチームは ソフトウェア開発ライフサイクル (SDLC) 全体に わたり、 規模に 応じて セキュリティポリシーを 自動で 展開・適用 できます。
5. 重要な指標を測定する 組織に よって 重視する セキュリティ指標は 異なる ため、 何が 最も 重要なのかを 判断し、 定量化する ことが 大切です。 デプロイ前に 排除した 脆弱性の 数、 デプロイ承認に かかる 時間の 短縮幅、 クラウドエンジニアリングの 生産性向上などを 追跡すると よいでしょう。 測定に よって 進捗を 確認できるだけでなく、 この 5段階の サイクルの 最初の 段階に 役立つ 重要な 情報も 得られます。
Snykの 顧客の うち、 クラウドセキュリティで 大きな 成果を 上げている 企業は、 常に 次の 5つの 取り組みを 実践しています。
Snykによる開発者ファーストのクラウドセキュリティ Snykは、 クラウドセキュリティに 関して 開発者が 直面する 課題を 認識し、 その 負担を さらに 軽減する ことを 目指しています。 クラウドセキュリティポスチャ管理を DevSecOpsの ワークフローに 統合する ことで、 組織が クラウド環境を より 深く 理解し、 より セキュアな システムを 設計し、 開発者が より 安全な ソフトウェアを リリースできるよう 支援します。
詳しくは、 ウェビナーの 全編を ご覧ください。 あらゆる クラウド侵害に 欠けている ストーリー— 知って おくべき こと、そして 実行すべき こと 。
開発者の ために 設計された IaCセキュリティ Snykは、 統合された ポリシー・アズ・コードエンジンに より、 SDLCから クラウドでの 実行時まで Infrastructure as Codeを 保護します。 すべての チームが 安全に 開発、 デプロイ、 運用できるよう 支援します。