セキュリティプログラムにおけるプラットフォームエンジニアの重要性

プラットフォームエンジニアが組織のセキュリティプログラムで力を発揮できる環境を整える必要があります。その仕事は、製品のセキュリティ態勢に大きな影響を及ぼします。アプリケーションの脆弱性と同等、あるいはそれ以上の影響があると考える人もいるほどです。これほど大きな影響をもたらす役割であるにもかかわらず、セキュリティプログラムにおけるその役割は明確に定義されていません。クラウドベンダーは顧客と共有する責任範囲を明確に定めていますが、アプリケーション開発者とプラットフォームエンジニアの間でセキュリティの責任をどう分担するかを明示している組織はほとんどありません。

このブログ記事では、プラットフォームエンジニアとは何かを解説し、プロダクトセキュリティチームが把握しておくべき課題をいくつか取り上げます。

プラットフォームエンジニアとは？

プラットフォームエンジニアは、組織内で開発者がセルフサービスを利用できるよう、ツールやシステムを構築します。開発者が選択肢の多さと引き換えに、認知負荷の軽減、使いやすさの向上、シンプルなソフトウェア開発ライフサイクルを得られる「舗装された道」を作ります。選択肢のパラドックスや険しい学習曲線に悩まされることなく、アプリケーション開発者は顧客に喜ばれる製品づくりに集中できるようになります。

プラットフォームエンジニアは、複雑で断片化された多数のインフラ構成要素を取り込み、機能を絞ったシンプルなコンポーネント群を提供します。つまり、レゴブロックを組み合わせて、デュプロのようなものを作るのです。

適切に構築されていれば、アプリケーション開発者はインフラの専門家にならなくても、業務の80%に必要なカスタマイズをすべて利用できます。

プラットフォームエンジニアリングとセキュリティの関係とは？

インフラそのものの細かな部分を抽象化する過程で、プラットフォームエンジニアは、そもそもインフラをどのように構成すべきかを決定します。こうした判断は、組織のセキュリティ態勢に大きな影響を与えます。設計上の欠陥や設定ミスは、アプリケーションの脆弱性よりもセキュリティプログラム全体に大きな影響を及ぼすとも考えられます。実際、Snykの「2021年版クラウドネイティブアプリケーションセキュリティの現状」レポートでは、回答者の45%が設定ミスに起因する脆弱性を経験していました。

一般的な社内開発プラットフォームの各レイヤーを設計、実装する際に起こり得るエラーを考えてみましょう。

• アプリケーション管理：ログエージェント、CD、コンテナオーケストレーション、シークレット管理、イメージレプリケーション、データのバックアップとライフサイクル、アーティファクトのビルドと保存

• アプリケーションのコンピューティング：コンテナクラスター、VM、ロードバランシング、証明書

• ネットワーク：DNS、分離ネットワーク、インターネット接続、インバウンド／アウトバウンドルール

• アクセス：ID、権限

プラットフォームエンジニアに話を聞けば、このリストはさらに長くなるでしょう。次に、プラットフォームエンジニアが直面する課題を見ていきましょう。

複雑化し続けるレゴの箱を安全に保つ難しさ

コンポーネントの数は多く、増え続けています。それぞれのコンポーネントも、ますます高度化しています。また、顧客がアーキテクチャの一部を外部のソフトウェアベンダーに委ねることで、マイクロサービスはSaaSへと移行しつつあります。

プラットフォームエンジニアは、特定の分野に深い知識を持つ一方で、幅広い領域を担当するジェネラリストであることが多くあります。セキュリティ脆弱性に関する知識のギャップは、アプリケーション開発者と同様に存在します。ただし、そのギャップはより多様で把握しづらいと言えるでしょう。多くの場合、特定のベンダーのサービスやその設定に関する深い知識が必要になるためです。

未成熟なテスト慣行によって深刻化する、複雑な変更管理

アプリケーション開発者にとって、テストはよく理解され、広く実践されています。開発者はコードのテストを作成し、テストピラミッド全体におけるさまざまなテスト戦略の利点と欠点を理解することが期待されています。その結果、アプリケーションのセキュリティ修正をマージするコストは比較的低く抑えられます。組織は、テストの成熟度によってデグレードを防げるため、セキュリティパッチのマージに必要なのはビルドの成功だけであることも少なくありません。

プラットフォームエンジニアリングでは状況が異なります。インフラのコード化は、業界全体でも企業内でも、まだゆっくりとしか進んでいません。何らかのテストを実施するための基本要件であるバージョン管理を超えても、インフラ変更のテスト慣行は明確に定義されていません。そのため、個々の変更に伴うリスクは高くなります。さらに、設定変更に含まれるすべての属性が同じように扱えるわけではありません。属性の更新、削除、追加によってリソースの置き換えが発生する場合があり、依存するリソースや、それらが支えるアプリケーションとユーザーに深刻な影響を及ぼす可能性があります。

現在、インフラの脆弱性を修正するには、より多くのコストがかかります。プラットフォームエンジニアは変更をデプロイする際の惨事を避けるため、個々の変更を神経質なほど慎重に確認しています。このやり方はスケールしませんが、まだ発展途上にあるプラットフォームエンジニアリングのコミュニティでは、ベストプラクティスが確立されていません。

セルフサービスが招く展開上の問題

プラットフォームエンジニアリングは、プラットフォームをプロダクトとして捉える考え方とも呼ばれ、ユーザーに舗装された道を提供し、開発者のセルフサービスを可能にすることを目指します。インフラ設定の変更など、プラットフォームエンジニア自身が全社のインスタンスに展開する変更もあります。一方、新しいHelmチャート、terraformモジュール、デプロイ用のorbs／プラグイン、計装ライブラリなど、アプリケーション開発チーム側で採用、インストールする必要のある変更も数多くあります。

こうしたバージョンの違いによって組織のセキュリティ態勢は変化します。わずか数チームの更新が遅れるだけでも、アプリケーションセキュリティチームが把握できないまま、セキュリティプログラム全体に問題が生じる可能性があります。

まとめ

こうした課題を踏まえると、プラットフォームエンジニアには、SDLCの早い段階で設定ミスを見つけるツールが必要です。さらに、テストにとどまらず、舗装された道の設計を改善するための支援も必要です。

プラットフォームエンジニアは、組織のセキュリティ態勢、ひいてはマルチベンダーやSaaSが主流となったソフトウェアの世界全体に、大きな影響を及ぼします。新たなベストプラクティスの確立とプラットフォームの成熟度向上への投資により、セキュリティリスクを排除、軽減できるだけでなく、アプリケーション開発者はこれまで以上に低コストかつ迅速にアプリケーションの脆弱性を修正できるようになります。