設計および開発ライフサイクルの後半にソリューションにセキュリティーを追加すると、多くの場合、コストがかかる再作業が発生し、ソリューションの成果とユーザー・エクスペリエンスを損なうユーザビリティーが犠牲になります。初期段階で安全なソリューションを設計すると、最終的なソリューションのユーザビリティー、相互運用性、レジリエンス、セキュリティーの適切なバランスを確保するのに役立ちます。

セキュア・バイ・デザインは、プロジェクトの設計、開発、デリバリーの実践には、熟練した経験豊富なチームによって実現されるセキュリティーとコンプライアンスの実践が含まれている必要があるという原則です。それに準ずるようなセキュリティー設計原則は、アーキテクチャー的思考の実践を導きます。

設計プロセスは、組織の内外を問わず、リスク、コンプライアンス、セキュリティーの利害関係者にとって必要なユーザーの成果に焦点を当てるために、エンタープライズデザイン思考を用いることから始める必要があります。外部の利害関係者には、顧客、政府、規制当局が含まれます。内部利害関係者には、リスク、コンプライアンス、およびセキュリティーを管理する関係者が含まれます。

設計プロセスはアーキテクチャー思考に基づいて、アーキテクチャーの特性、アーキテクチャーの決定、機能的アーキテクチャー、クラウド・デプロイメント・モデルを定義します。その後、セキュリティー・サービスのレジリエンス、性能、拡張性などの特性の定義が完了します。

要件とアーキテクチャーを定義したら、「セキュア・バイ・デフォルト」原則に従うなど、セキュリティー機能とインフラストラクチャーのエンジニアリングを実行できます。

IBMは、製品開発に使用するセキュリティーとプライバシー・バイ・デザインに対する長年のアプローチを採用しています。開発のセキュリティーに関する公開済みのIBM Redpaper：IBM Secure Engineering Frameworkは、レビューに役に立ちます。

システムを使用するユーザーまたはソフトウェアに過剰な権限が付与されている場合、誤ってまたは故意に悪用されるリスクがあります。脅威アクターは、内部ユーザーの特権アカウントを侵害し、その権限を使用してネットワークやシステムを通過する可能性があります。

最小権限とは、システムがユーザーやソフトウェアに、意図したタスクを実行するために必要な最小限の機能を与えるべきであるという原則です。システムは、アプリケーションの最上位レベルから2つのソフトウェア・コンポーネント間の個々の接続まで、これを実装する必要があります。

最小権限の原則を実現するには、動的なIT環境内の資産を理解する必要があります。特権アクセスは人だけの問題ではありません。どのアプリケーションがどのデータにアクセスできるかを知る必要があります。検出、分類、リスク評価のプロセスは継続的です。デジタル資産からリスクデータを統合することで、新たなビジネスレベルのリスク洞察を明らかにし、適切なポリシーを確立するのに役立ちます。

ユーザーまたはソフトウェアは、セッションの最初の識別と認証の時点で安全なコンテキストを持っている可能性がありますが、脅威アクターはアクティブなセッションを侵害し、それを使用してシステムをさらに侵害する可能性があります。

継続的な検証は、ユーザーまたはソフトウェアが安全なコンテキストを保持しているかどうかを評価するために常に検証する必要があるという原則です。継続的な検証の目的は、セキュリティーの問題と脆弱性をできるだけ早期に発見することです。理想的には、脅威アクターがそれを発見します。

継続的な検証により、エンティティーが、第2要素認証リクエストなどのチャレンジを使用していると主張する人物または内容であることを確認します。ワークロードは、ゼロ・トラスト・ネットワーク・アーキテクチャー（ZTNA）を使用するソリューションを使用して、ユーザーとソフトウェアの継続的な検証をサポートするために更新が必要な場合があります。クラス最高のユーザー・エクスペリエンスを提供することに重点を置いている組織は、不要な要求でユーザーを混乱させることに躊躇します。ただし、このレベルのID保証はゼロトラストにとって必要不可欠です。

脅威アクターはすでに組織に侵入している可能性があります。組織が外部Boundaryの脅威のみを探し、有効なメカニズムを使用してBoundary制御を回避した脅威を探す場合は、長期間にわたって侵害を発見できない可能性があります。侵害前提とは、組織が、侵害が脅威アクターによって発生していることを前提とする原則です。

このアプローチでは、脅威管理によりプロアクティブな内部検知、早期警告サインの検知、脅威ハンティング、実績のあるランブックの使用を追加することが求められます。検知と対応は洞察層と適用層に緊密に統合し、コンテキストを共有し、特定された脅威に対応してアクセス制御ポリシーを動的に調整する必要があります。

情報システムには、ソフトウェア、ファームウェア、ハードウェアに脆弱性が発生することがあります。構成やソフトウェアが変更され、新たな脆弱性が発生します。1つの防御層が脆弱な場合、システムの安全性を維持する必要があります。

徹底した防御とは、ある層で障害が発生しても別の層を維持してシステム内の機密データを保護できるように、システムに複数の防御層を持たせるという原則です。セキュリティー戦略に対して多層アプローチを採用すると、組織はある1つの防御層を突破した場合でも、後続の層で攻撃者を阻止できるようになります。

エンタープライズ・セキュリティー・ストラテジーおよびアーキテクチャーには、従来のネットワーク・コンピューティング・モデルの後続の層全体を保護する対策を含める必要があります。一般的に、組織は最も基本的なもの（システム・レベルのセキュリティー）から最も複雑なもの（伝送レベルのセキュリティー）まで、セキュリティーを計画する必要があります。

組織の攻撃対象領域とは、脅威アクターがネットワークや機密データへの不正アクセスを手に入れたり、サイバー攻撃を実行したりするために利用できる脆弱性、経路、または手法（攻撃ベクトルと呼ばれることもあります）全体を指します。クラウド・サービスやハイブリッド（オンプレミス／在宅勤務）ワークモデルの導入が進む中で、企業のネットワークや関連する攻撃対象領域は、日に日に拡大し、複雑化しています。

攻撃対象領域の最小化とは、システムが攻撃ベクトルの範囲を縮小して、脅威アクターがアクセスする可能性のある方法を減らすべきであるという原則です。セキュリティーの専門家は、攻撃対象領域を、デジタル攻撃対象領域、物理的攻撃対象領域、およびソーシャル・エンジニアリング攻撃対象領域という3つのサブ対象領域に分けています。

1. デジタル攻撃対象領域により、組織のクラウドやオンプレミスのインフラストラクチャーは、インターネット接続を使用したあらゆる脅威アクターに対して無防備になっている可能性があります。一般的な攻撃ベクトルには、ネットワーク・アクセス、ソフトウェアの脆弱性、未使用リソースの有効化、シャドーIT、データ停止ソフトウェアなどがあります。

2. 物理的攻撃対象領域は、通常は、組織の物理的なオフィスまたはエンドポイント・デバイスへのアクセスを許可されたユーザーのみがアクセスできる資産や情報を公開します。これには、悪意のあるインサイダーによる攻撃、デバイスの盗難、「ベイティング」が含まれます。「ベイティング」は、脅威アクターが、マルウェアに感染したUSBドライブを公共の場所に置き、ユーザーを騙してユーザーのコンピューターにそのデバイスを接続させて、意図せずにマルウェアをダウンロードさせる攻撃です。

3. ソーシャル・エンジニアリングの攻撃対象領域は、人々を操り、共有すべきでない情報を共有させたり、ダウンロードすべきでないソフトウェアをダウンロードさせたり、訪問すべきでないWebサイトへアクセスさせたり、犯罪者に送金させたり、個人または組織の資産やセキュリティーを危険にさらすその他のミスを犯させたりします。

組織は、これらの攻撃対象領域をそれぞれ調査するシステムによって処理される機密データのリスクを評価する必要があります。

ユーザーは、暗号化キーなどの制御のバイパスを可能にする機密性の高いデータにアクセスしたり、多額の送金など、高度に特権化されたアクションを実行する権利を取得したりする可能性があります。システムがユーザーを監視している場合でも、ユーザーはユーザーの権利を侵害し、ビジネスに壊滅的な影響をもたらす可能性があります。

職務の分離とは、データまたはアクションへの強力なアクセス権を持つユーザーがそのアクションを完了するためには、複数のユーザーが必要であるという原則です。これにより、組織は、重複した責任を負うことなく管理機能を個人に分割できるため、1人のユーザーが無制限の権限を保持することはありません。

暗号化キーの管理などの活動により、組織は暗号化キー管理者にキーのさまざまな部分を管理することを義務付け、1人の管理者がキー全体を把握することができないようにします。ビジネス取引の場合、アプリケーションはトランザクションを要求する人に、トランザクションが完了するために1人以上の承認者を必要とする場合があります。

業界によっては、規制ガイダンスの一環として、規制当局が強力な機能に対して職務の分離を要求する場合があります。職務の分離により、企業は官公庁・自治体の規制を遵守し、当局の管理を簡素化することができます。

製品やサービスにはさまざまな構成ポイントが含まれており、できるだけ使いやすくしたいと考えています。結果的に、製品には、ネットワーク・ポートが開いたり、パスワードを簡単に覚えたりするなど、安全でないセキュリティー構成が適用されています。

セキュア・バイ・デフォルトとは、組織がすぐに安全な状態で構成された製品やサービスを受け取るという原則です。この製品は、エンドユーザーが脅威や脆弱性を保護するための追加の手順を実行する必要がなく、最も蔓延している脅威や脆弱性から保護するように設定されています。

システムは最初は安全に設定されていても、その後、開発者が構成を変える変更を行ったり、脅威アクターがシステムを危険にさらす脆弱性に対して変更を加えたりする可能性があります。

継続的コンプライアンスとは、システム開発から継続的な実行に至るまで、システムのセキュリティー構成を常にチェックするという原則です。継続的コンプライアンスの目的は、脅威アクターよりも先に、セキュリティーの問題と脆弱性を発見することです。

理想的には、コンプライアンス・チェックはすべて自動化され、クラウド・プラットフォーム、コンテナ・プラットフォーム、ミドルウェア、仮想サーバーやコンテナなどのコンピューティング・イメージを含むすべてのセキュリティー構成をカバーします。コンピューティング・イメージの場合、Infrastructure as Code（IaC）を使用して、イメージ全体を定期的に置き換える方が良い場合があります。

ハイブリッドクラウド環境でセキュリティーとコンプライアンスを実現するための共同責任は、ワークロードまたはアプリケーションで使用されるサービス・モデル、コンピューティング・プラットフォーム、クラウド・サービス・プロバイダーによって異なります。セキュリティー・アーキテクトは、セキュリティー・サービスの設計、構築、実行に関する責任を文書化して、伝える必要があります。明確にしておかないと、ソリューションのセキュリティーに隙間が生じるおそれがあります。

各側面は、共同責任にそれぞれ異なる影響を及ぼします。

• クラウド・サービス・モデル-NISTのクラウド・コンピューティングの定義では、IaaS、PaaS、SaaS、分散クラウドなど、クラウド・サービス・モデルによって責任の範囲が異なります。セキュリティー・サービスは共同責任の一部です。たとえば、IBM Cloudの共同責任には、IDおよびアクセス管理、セキュリティーと規制コンプライアンスが含まれます。これらのカテゴリーにおける共同責任は、クラウド・サービス・モデルによって異なります。
  

• コンピューティング・プラットフォーム - ワークロードのホスティングは、ベアメタル・サーバー、仮想サーバー、コンテナ・プラットフォーム、サーバーレスなどの1つ以上のコンピューティング・プラットフォームです。コンピューティング・プラットフォームに応じて共同責任は異なります。たとえば、ベアメタル・サーバーでは、ワークロードの所有者が、物理ハードウェアと統合を除くプラットフォーム上のすべてのセキュリティー管理に責任を負う必要があります。
  

• クラウド・サービス・プロバイダー - 責任は、クラウド・サービス・プロバイダーによっても異なります。たとえば、各クラウド・サービス・プロバイダーのKubernetesプラットフォームは（Red Hat OpenShiftを使用している場合を除いて）異なり、それぞれが異なる厳選されたオープンソース・パッケージのセットで構成されています。

では、セキュリティー・アーキテクトはなぜサービス所有権の違いに注意を払う必要があるのでしょうか？セキュリティー運営を行うチームは、サービスの実行をサポートするためにセキュリティー・サービスを事前に定義している場合があります。セキュリティー・サービスはクラウド・プラットフォームの一部である場合もあれば、広範な統合が必要なオンプレミス環境であることもあります。

たとえば、社内のセキュリティー運用チームは、IBM Consultingなどのグローバル・システム・インテグレーター（GSI）とは異なるテクノロジーを使用する場合があります。内部セキュリティー・チームの場合、セキュリティー・サービスをホストする制御プレーンはオンプレミスである場合がありますが、GSIは別のクラウド・サービス・プロバイダーが提供するクラウド・サービスを使用することがあります。

サービス型ソフトウェア（SaaS）クラウド・サービス・モデルでは、クラウド・サービスの利用者が利用できるのはアプリケーション・セキュリティー管理のみとなります。セキュリティーは通常、サービスの一部としてアプリケーションに組み込まれており、セキュリティー構成を制御できる範囲は限られています。この場合、SaaSプロバイダーがセキュリティー運用の責任の大部分を担います。

責任が文書化されていない場合、ワークロードの実行に依存するセキュリティー・コンポーネントの設計、構築、実行を担当する所有者が割り当てられない可能性があります。セキュリティー・サービスに対する共同責任を理解することで、ソリューション・アーキテクチャーが運用上のニーズを満たし、プロジェクトの後の段階でソリューションの手直しを回避できます。

ハイブリッドクラウド・アーキテクチャーのセキュリティー・サービスは、さまざまなクラウド・サービス・モデル、コンピューティング・プラットフォーム、クラウド・サービス・プロバイダーを利用します。これらのサービスでは、セキュリティーとコンプライアンスの一貫した管理と監視を行うために、合意された制御プレーン・アーキテクチャーが必要です。

オンプレミスのデータセンター・ワークロードがある企業では、クラウド・サービス・プロバイダー由来の障害に強くなるため、制御プレーンをオンプレミスのデータセンターに配置できます。ただし、オンプレミスのセキュリティー・サービスは必ずしもクラウド・プラットフォームを完全に管理できるわけではありません。そのため、さまざまなクラウド・サービス・プロバイダーの間でセキュリティーの状況を報告し、リスクを特定するための制御プレーン・アーキテクチャーを設計します。

クラウド生まれの組織では、制御プレーンのホスティングは、別のクラウド、ポイント・オブ・プレゼンス（POP）、または共同データセンターでホストされる可能性があります。クラウド・サービス・プロバイダーで障害が発生した場合でも、セキュリティー制御プレーンを利用可能にする必要がある場合があります。

セキュリティー・アーキテクトとして、組織全体のセキュリティー制御プレーン・アーキテクチャーにおける整合性を確保するために、アーキテクチャー上の決定を文書化して合意することが重要です。ソリューションが組織の目標を確実に満たすように、プロジェクトの早い段階でこの決定を行ってください。

セキュリティーとは、主にセキュリティー機能を導入することではなく、ビジネス・データとプロセスを脅威から保護することです。体系的なアプローチを使用して、システム内のデータ・フローを追跡し、転送中、保存中、使用中のデータを保護するセキュリティー制御を特定します。

アーキテクトは、システム・コンテキスト図から着手して、システムの境界と、システムを通るデータ・フローを開始する外部とのやり取りを特定することで、保護対象の機密データを特定する必要があります次に、コンポーネント図などの機能コンポーネントを説明する図を使用して、アプリケーションの内部データ・フローを調べます。

アーキテクトが実装に進む際には、クラウド・アーキテクチャー図を使用して、クラウド・インフラストラクチャーに導入されたコンポーネント間のデータ・フローを調査します。IBMは、クラウド・サービス・プロバイダーに依存しない設計を可能にする技術図設計言語を開発しました。

これらのデータ・フローに対する脅威を特定するには、ワークロードの機能コンポーネントとワークロードのインフラストラクチャーの両方に対して脅威モデリングを使用します。

これらの手法と成果物を組み合わせることで、セキュリティーとコンプライアンスのアーキテクチャー思考に対する、繰り返し可能で一貫したアプローチが実現します。

最も機密性の高いデータを処理する場合は、機密コンピューティングと準同型暗号を使用することで、別の保護層を検討してください。

システムはさまざまな制御要件を満たす必要があり、そのリストは長くなり、管理が困難になる場合があります。多くの個別の要件を扱うのではなく、要件を提供機能にグループ化するプロセス、サービス、または機能に取り組みます。たとえば、IDライフサイクル管理や未承認コンポーネントの検知が潜在的な提供機能になります。

コンプライアンスをより効果的に管理するには、次の手順に従ってください。

1. 元のソースまで追跡可能な単一のコンプライアンス・フレームワークを作成します。
2. コンプライアンス・フレームワークの要件を一連の提供機能にマッピングします。
3. 設計、構築、テスト、運用のすべての段階でコンプライアンス機能を確保します。
4. 本番環境の要件に継続的に準拠します。

セキュリティー・アーキテクトは、セキュリティー機能にサービス・レベル目標（SLO）や責任契約などが関連付けられていることを確認する必要があります。

多くの場合、ある顧客、事業部門、または環境からのデータが他の顧客、事業部門、または環境に漏洩しないようにする必要性が生じます。ワークロードの実行とデータ保管のために、分離を行う必要があります。データベース内の別のテーブルや別の物理サーバーを使用するだけのシンプルな場合もあります。

ハイブリッドクラウドには、データ処理の分離を実施するためのオプションが多数用意されています。分離は次の間で行う必要があります。

1. ワークロードまたはアプリケーション - 経理と人事など
2. 環境 - 開発、テスト、本番など
3. 顧客 - 顧客Aと顧客Bなど
4. 場所 - 英国と米国など

ハイブリッドクラウド環境内の分離にはさまざまな選択肢があり、それぞれに異なる機能と保証が提供されます。

1. エンタープライズ・アカウント
2. クラウド・アカウント
3. リソース・グループ
4. 仮想プライベートクラウド
5. 実行ドメイン - コンテナやサーバー・イメージなど
6. プロジェクト
7. キー管理ドメイン
8. 物理デバイス

データを処理するワークロードに適した分離の種類を組織のポリシーで定義する必要があります。たとえば、本番環境の顧客データのホスティングが非本番環境で行われないことがポリシーで求められる場合があります。最低限必要な分離レベルは、IDとアクセスの管理が行われる別のクラウド・アカウントです。

データ分離のトピックに関連するのは、データ主権のトピックです。特定の国または地域では、データの処理とアクセスが行われる場所に制約が課されています。ブログ記事「ソブリン・クラウドによる規制への対応とイノベーションの推進」では、データ主権のニーズの階層について説明しています。

脅威モデリングは多くの場合、システム内を流れるデータのセキュリティー制御を特定して検証するための手法として考えられています。

脅威モデリングには2つ目の目的があります。それは、脅威モニタリング・システムで監視する脅威を特定することです。セキュリティー・アーキテクトは、優先順位付けされた脅威リストを特定する作業に取り組む必要があります。次に、脅威検知機能に必要な脅威検知のユースケースを定義します。脅威への効果的な対応を実現するために、インシデント対応手順で検知ユースケースを実装およびテストします。

脅威、脅威防御ユースケース、およびインシデント対応手順間で文書化されたトレーサビリティーを確保して、プロジェクトの完全な設計と提供を保証します。

これまでのオンプレミスのデータセンターでは、セキュリティー運用チームは数日または数時間で作業を完了でき、厳格なサービス・レベルは必要ありませんでした。コード型インフラストラクチャー（IaC）の自動化によって、機密情報や証明書管理などの一元化されたセキュリティー・サービスが失われると、アプリケーションの可用性に即座に影響が出ます。そのため、セキュリティー・サービスには、可用性要件を満たすサービス・レベルとアーキテクチャーが必要です。

セキュリティー機能またはサービスごとに以下を定義します。

1. サービス時間
2. インシデント、問題、変更の応答時間
3. 運用スタッフのスキルと経験
4. サービス要件に合わせた詳細なテスト手順
5. サービス要件に合わせた自動化

社内のセキュリティー運用チームがクラウドネイティブのワークロードの要求に対応できない場合は、マネージド・セキュリティー・サービス・プロバイダーが適切かどうかを検討してください。

よく考えてみると、今日の多くのセキュリティー・サービスには、サポートするワークロードと少なくとも同程度のレジリエンスとサービス・レベルが必要です。

従来の作業方法では、セキュリティーは後回しであり、開発ライフサイクルの早い段階でセキュリティーの構成とパッチ適用を完了することが困難でした。DevOpsの作業慣行では、セキュリティーの構築基準は次のようにする必要があります。

1. 開発環境とテスト環境に組み込む。
2. 開発初期から本番稼働まで一貫性を保つ。
3. 継続的なコンプライアンスに対し継続的にテストする。

ビルド・プロセスは、開発と運用のすべての段階でワークロードの安全でない展開を防止し、セキュリティーが後回しにされないようにする必要があります。