クラウド アーキテクチャに設計上の規制コンプライアンスを組み込むための 10 のヒント

2 人の業界専門家が、スターバックスのモバイル アプリをサポートするために必要なチームとプロセスを構築する過程で得た経験と教訓を共有します。

[[283295]]

最近開催されたインターネット セキュリティ カンファレンスでは、スターバックスが大規模なクラウド コンピューティング プロジェクトを構築するのを支援した 2 人のセキュリティおよびコンプライアンスのリーダーが講演しました。数年前、スターバックスは、コンプライアンス自動化スタートアップ企業 Shujinko の創設者である Matt Wells 氏と Scott Schwan 氏に、ペイメント カード業界 (PCI) に完全に準拠し、インターネット セキュリティ センター (CIS) が設定した標準に照らして評価された安全なクラウド アーキテクチャを使用して、スターバックスのモバイル アプリをサポートするために必要なチームとプロセスを構築するよう依頼しました。

「スターバックスが発売したいすべての製品をサポートするために使用できる、高度に自動化され、拡張可能で、繰り返し可能な環境を構築するのに、当社では 20 人のエンジニアが約 9 ～ 12 か月かかりました。そして、スターバックスはそれを基盤として、他のアプリケーションをパブリック クラウドに移行し始めました」と、Shujinko の CTO である Matt Wells 氏は説明します。

Shujinko の CTO である Matt Wells 氏と CEO である Scott Schwan 氏が、Starbucks での取り組みの詳細について掘り下げ、クラウド アーキテクチャにコンプライアンスを組み込み、その過程で DevSecOps を拡張する方法に関するヒントを共有します。彼ら自身の言葉による洞察をいくつか紹介します。

1. コンプライアンス要件を「完了」の定義に組み込む

「エンジニアリング チームにとって、コンプライアンス要件を「完了」の定義に組み込むことは非常に重要です」と Matt Wells 氏は述べています。 「多くの場合、チームは会話を開始せず、議論を早めに行いません。その結果、「完了」の定義にはコンプライアンスやセキュリティに関連するものは一切含まれません。そのため、チームにとってそのつながりを作ることが極めて重要です。」

2. エンジニアに環境保護の直接的な責任を持たせる

「ある特定のケースでは、私たちはクラウドプラットフォーム全体を構築しており、そのプラットフォームのセキュリティに責任を負っていました」とマット・ウェルズ氏は語った。 「早い段階で期待値を設定し、『これは重要です。このチームに参加したいのであれば、非常に優れたテクノロジーを使用することになりますが、セキュリティとコンプライアンスの責任はあなたにあります。監査に合格しない場合は、セキュリティ チームやコンプライアンス チームの責任ではなく、私たちのチームの責任になります』と言うことができるようにすることです。」

3. クラウドエンジニアリングチームとセキュリティチーム間の強力な連携を構築する

「我々は最初からセキュリティのリーダーシップと本当に足並みを揃えるようにした」とシュワン氏は語った。 「私はDevSecOpsの基本原則を信じています。エンジニアリングチームが自分たちが構築している要件を理解していれば、セキュリティチームがプロジェクトの最後に飛び込んできて変更したりブロックしたりするのではなく、その役割に責任を負うことができます。そのため、文化的な変化の一部は、チーム間の信頼を確実に構築することでした。」

4. 構築前にセキュリティ手順と要件を定義する

「私たちはセキュリティ チームから要件を収集し、サポートする必要のある地理的地域のビジネス グループからコンプライアンス要件を収集しました」と Matt Wells 氏は述べています。 「私たちは遵守しなければならないコンプライアンス基準をすべて持っていて、それぞれに異なる要件がありました。そこから手順を定義しました。それでは、どうやってサーバーにパッチを適用するのか？コンテナを導入してコードを展開するにはどうするのか？

エンジニアがインフラストラクチャを構築する際、これらの手順が特定のテクノロジーの構築方法に影響を与えることがあるため、構築前にこれらの手順を整備しておくことが重要だと考えています。私たちにとって、これは設計段階です。 ”

5. エンジニアリングチーム内にセキュリティの専門知識を組み込み、トレーニングする

Matt Wells 氏は次のように語っています。「設計後、多くのスタッフを雇用し、不足しているスキルを身につける必要がありました。そこで、セキュリティ担当者、開発者、運用担当者のグループを雇用しましたが、セキュリティ担当者や運用担当者よりも多くの開発者が必要であることがわかりました。私たちは自動化とスケールに重点を置いていたため、開発者を招き入れ、セキュリティ担当者や運用担当者が開発者と協力して、開発者がこれらの機能の多くをどのように構築するかを定義する方が簡単だとわかりました。プロのセキュリティ担当者を直接雇用したわけではありませんが、開発者をセキュリティ担当者になるようにトレーニングしました。」

6. 規制に従って環境を自動的に強化する

Matt Wells 氏は、次のように述べています。「当社にとって、構築するものすべてを自動的に強化することが大原則です。最初に行ったのは、Terraform を使用して AWS アカウントの構成と強化を自動化することでした。AWS アカウントの構築、ログ記録、パスワード ポリシーの設定などに 1 日または数時間を費やす代わりに、Terraform を使用して 1 週間かけて AWS アカウントを構築しました。しかし、長い目で見れば、AWS アカウントに何か新しいものを設定するたびに、エンジニアに「パスワード ポリシーを設定しましたか?」と尋ねるのではなく、Terraform を使用して AWS アカウントを構築することで、セキュリティとセキュリティの両方の面でメリットがもたらされました。あるいは、「丸太はどこへ行くのか？」 「『Terraform スクリプトを実行して強化しましたか? これで次に進めます』と言えばよいのです。」

7. 自動ガードレール

スコット シュワン氏は、「私たちは、新しい環境をスキャンして PCI 要件を調べるベンダーを利用しました。そのため、スクリプトを実行した後、すぐに実行してレポートを提供しました。PCI の問題がまだ発生している場合は、スプリントに戻って Terraform のインフラストラクチャ コードに問題を追加するようにしました。そうすれば、次回セットアップするときには、同様の問題は発生しません。」と述べています。

これは、AWS が現在持っているツールやサービスの一部を導入する前のことでした。その前に、彼らが持っていなかったものなので、私たちがそれを構築する必要がありました。私たちは、それがチームの精神に組み込まれていることを確認します。当時、彼らは CIS ベンチマークを使用し、良好なフィードバックを得て、すぐに修正し、コードに再度追加しました。 ”

8. コンプライアンスベースのテストをユニットテストに組み込む

「私たちは常に準拠したコードを実行していることを確認する必要があり、その一部はコンプライアンス ベースのテストを通じて行われます」とスコット シュワン氏は述べています。 「私たちは常に、できるだけ早く行動することでコンプライアンスに違反しないようにしています。

私たちは、機能単体テストだけでなく、セキュリティ テストやコンプライアンス テストも含め、コードの単体テストを書き始めました。私たちは、チームが新しいサービスを展開するたびにコンプライアンス標準をテストしていることを確認したいと考えています。パスワードポリシーが設定されていますか? ログ記録は有効になっていますか?それは機能横断的です。これらのユニット テストを書くのはセキュリティ エンジニアだけではありません。チームメンバーもこれに責任を負う必要があります。 ”

9. 可能な限りクラウドネイティブコントロールを使用する

「私たちがここで行っていることの 1 つは、可能な限りクラウド ネイティブ コントロールを使用することです」と Matt Wells 氏は述べています。 「クラウド ネイティブとは、コントロールがクラウドで提供されるという意味ではありません。クラウドに組み込まれたコントロールを使用するという意味で、クラウド プロバイダーから提供される場合もあれば、ベンダーから提供される場合もあります。すべて状況によります。」

10. ギャップ評価においてエンジニアが重要な役割を担う

マット・ウェルズ氏は、「ビルドフェーズの最後には、プログラムを完成させることに重点を置き、想定していたとおりに動作するかを確認します。ほとんどの場合、うまく動作しますが、場合によってはプログラムを変更する必要があります。最も重要なのは、実際にプログラムを完成させて検証したことです。」と述べています。

これにはギャップ評価作業が必要でしたが、それを構築したエンジニアに引き継ぎ、評価責任をチーム全体に分散しました。彼らは環境を誰よりもよく理解しています。なぜなら、環境に対して責任を持ち、「確かにギャップはあるので、それに対処しなければなりません」と言うからです。 '"