ワークロード保護とは

多くの人は、ワークロードの保護はクラウド サービス プロバイダーの固有の責任であると誤解しています。 たとえば、アマゾン ウェブ サービス (AWS) を利用している場合、Amazon がワークロードの保護に責任を負っていると考えるかもしれません。 しかし、これは真実からかけ離れています。 セキュリティは共有責任であり、各クラウド プロバイダーは、プロバイダーとクライアントのセキュリティ責任を明確に示す責任共有モデルを開発しました。 たとえば、アマゾン ウェブ サービスはインフラストラクチャのセキュリティを担当するのに対し、クライアントはそのインフラストラクチャ内で実行されるデータとアプリケーションのセキュリティを担当すると概説しています。 Microsoft Azure と Google クラウド プラットフォームには同様のモデルがあります。 彼らは自分たちの側でセキュリティを向上させるための集中的な努力をしており、ワークロードを管理して保護するのはクライアントの責任です。

多くの組織では、ワークロードの保護が開発者の焦点となっており、最新のクラウド アプリケーションとワークロードに関するワークフローと効率を向上させることを唯一の目的として、 DevSecOps チーム全体が創設されています。 しかし、物事はどのように異なるのか、利害関係は何か、そしてそれを改善するためにどのようなステップを踏むべきでしょうか?

ワークロード保護における一般的な脅威

ワークロード保護が防止しようとする一般的な脅威のいくつかを見てみましょう。

• アカウントの窃盗。 また、サイバー犯罪者がアカウントを乗っ取り、あなたやあなたの従業員になりすまそうとする場合もあります。 ここでの最も一般的な方法には、フィッシングやソーシャル エンジニアリング (誰かが権威者になりすましてログイン資格情報を横取りする) などがあります。
• APIアクセス。多くの場合、API が弱点となります。 API インフラストラクチャを使用すると、2 つ以上のアプリケーションが相互に「通信」し、特定の方法でデータを交換できます。 これらは多くの場合、簡単にアクセスでき、保護が難しいため、ハッカーの一般的な標的になります。
• サードパーティの脆弱性。同様に、サードパーティのツールを統合している場合、または外部パートナーと連携している場合、そのサードパーティに脆弱性があると、最終的にはさらに脆弱になる可能性があります。
• DDoS攻撃および類似の攻撃。 分散型サービス妨害攻撃 (DDoS) 攻撃では、サーバーがリクエストで圧倒され、適切に機能できなくなります。 このようなスタイルの攻撃は、多くの場合、十分に早期に検出されれば防ぐことができます。
• 従業員のミス。 一部の脆弱性は従業員の単純なミスが原因です。 従業員がセキュリティのベスト プラクティスに従わない場合、自分のアカウントだけでなく、組織のネットワーク全体が危険にさらされることになります。 たとえば、脆弱なパスワードを選択したり、一般的なスキームに引っかかったり、2要素認証の使用を怠ったりする可能性があります。 ここでは、従業員の教育、トレーニング、およびセキュリティのベストプラクティスの実施がすべて役立ちます。

これらの脅威は、厳しい罰則を伴うデータ侵害につながる可能性があります。 悪意のあるアクターがシステムにアクセスすると、保護されたデータ、機密データ、またはその他の機密データにアクセスできる可能性があります。 規制コンプライアンス、関係するデータの範囲、およびそのデータが将来どのように使用されるかによっては、ビジネスに数百万ドルの復旧費用がかかる可能性があります。

ワークロード保護へのアプローチ

では、ワークロード保護を改善するためにどのような手順を踏むことができますか?

新たなクラウド ワークロードや最新のアプリケーションの仕組みに合わせて設計された適切なソフトウェアやツールの実装など、実行する必要がある手順は数多くあります。 また、セキュリティチームと開発チームの構成を見て、適切なスキルセット、継続的なトレーニング、組織のセキュリティを維持する責任を分散させる必要があります。 最近では、セキュリティはチームワークで行う必要があります。

すべての新しい取り組みにおいて、これらを最優先事項とすべきです。

• 可視。 まず、すべてのシステムの可視性を高める必要があります。 サーバーがどのようなトラフィックパターンを認識しているかを把握し、内部ユーザーがデータにどのようにアクセスしているかを理解する必要があります。 可視性が高まるほど、潜在的な脅威をより早く検出できるようになり、組織の脆弱性についてより多くのことを知ることができます。
• コントロール。 優れたシステムには、多くの直接的な制御も存在します。 サーバーやネットワークへのアクセス方法をカスタマイズして、特定のソースをホワイトリストまたはブラックリストに登録できる必要があります。 また、システムのユーザーと管理者を厳密に制御する必要があります。承認されていない場合は、誰もアクセスできません。
• オートメーション。 理想的なセキュリティシステムには、大幅な自動化が必要です。 自動化されたソリューションは、時間とコストを節約するだけでなく(手作業に取って代わるため)、人為的ミスの可能性も減らします。 たとえば、異常なトラフィック アクティビティを自動的に検出し、DDoS の脅威を軽減するためのアクションを実行するソリューションがあるとします。 自動化には、特に正しく実行されない場合にいくつかの欠点がありますが、ほとんどのアプリケーションでは価値があります。
• 統合。 理想的には、さまざまなセキュリティアプリやサービスを統合できることです。 すべてのセキュリティソリューションを単一のダッシュボードまたは直感的なプラットフォームで管理でき、チームが使用する各アプリやサービスの強みを活用する必要があります。

シフトレフトの原則

ワークロード保護 は、開発ライフサイクルの早い段階で タスクを実行する必要があるソフトウェアテストとシステムテストのアプローチである「 シフトレフト 」テストの原則を中心にしています。セキュリティテストを「左」から開発にシフトする。

シフトレフトの主な原則は次のとおりです。

• プロアクティブ。 アクティブな脅威に対応して排除しようとするのではなく、脅威が重大になる前に検出して排除することに重点を置きます。 早期かつ頻繁にテストを行うことで、これまでにない可視性が得られ、最大の脅威の一歩先を行くことができます。
• コラボレーション。 また、シフトレフトでは、個人やチーム間のコラボレーションが求められますが、チーム間では、お互いに協力し合うことに慣れていないかもしれません。 セキュリティは、テスト担当者、開発者、および組織内のその他の人々が集合的に優先するものであるべきです。このようにして、ビジネス全体がより多くの脅威から保護されます。
• 継続的なフィードバック。 シフトレフトには、継続的なフィードバックの原則も組み込まれています。 セキュリティは、一度計画して実行するものではありません。これは、ロールアウトし、学習するにつれて徐々に調整するものです。

シフトレフトの考え方は、さまざまな脅威から身を守り、組織に干渉する前にほとんどの問題に対処するのに役立ちます。 適切なワークロード保護プラクティスと組み合わせることで、組織にはるかに堅牢なセキュリティを提供できます。

より優れたクラウド ワークロード保護を組織に組み込むことに興味がありますか? 生活を簡素化できるクラウド セキュリティ ツールの恩恵を受ける可能性があります。 当社のクラウド セキュリティ ソリューションをご覧になり、今すぐ無料デモにサインアップしてください。