組織 (Open Source)

組織 → アセット → エンゲージメント → テスト → 検出事項

概要#

組織は、DefectDojoのオブジェクト階層の最上位に位置します。組織は、階層内の下位オブジェクト(アセット、エンゲージメント、テスト、検出事項)とは異なり、技術的なスキャン対象ではなく、主に以下の観点でセキュリティ活動を区分するための組織的な抽象概念として機能します。

• ビジネスドメイン
• 開発チーム
• セキュリティチーム
• ソフトウェアアプリケーション
• 包括的な製品ファミリー
• 顧客または子会社
• レポート体制
• など

上記の例に共通するテーマは、組織の本質的な役割を示しています。組織は基本的に、セキュリティプログラム内で安定した長期的な境界を表すべきものです。

組織のデータと構造#

組織は直接スキャンされる対象ではないため、作成時に必須となるフィールドは名前のみです。それ以外の点では、組織はアセットおよびその下位にあるエンゲージメント、テスト、検出事項を格納するコンテナとして機能します。

組織を作成する際は、その構造がレポートにどのような影響を与えるかを考慮してください。組織に含まれるプロジェクト(アセット)に取り組むチームを表すことを主な目的とするのか、それとも組織内に含まれる複数のプロジェクト(アセット)の反復版をまとめた、より包括的なプロジェクトを表す方が適切なのか、検討する必要があります。

特定のビジネスドメインや開発チームに関連するすべての情報を1つの組織にまとめられる場合、それを組織として表すことで、複数のアセットや組織からレポートをまとめる手間が省け、より円滑なレポート作成が可能になります。

特定のソフトウェアプロジェクトに多数の異なるデプロイメントやバージョンが存在する場合、プロジェクト全体の範囲をカバーする単一の組織を作成し、各バージョンを個別のアセットとして存在させる方法が有効な場合があります。また、ワークフローによっては、組織をソフトウェアのライフサイクル段階を区分するために使用することもできます。たとえば、「開発中」用の組織と「本番稼働中」用の組織を分けて作成する、といった形です。

組織は、RBAC(ロールベースアクセス制御)の目的で、子会社、買収した企業、その他の規制対象事業単位へのアクセスを決定するために使用できます。異なるアクセスルールを持つ独自のプロジェクトが多数存在する複雑な事業においては、組織が特に重要な役割を果たします。

最終的に、組織とアセットをどのように使い分けるかは、自社独自の組織構造やセキュリティチームのニーズをどのように反映させたいかによって決まります。

以下に、オブジェクトを組織またはアセットのどちらに割り当てるかを判断する際の参考となる、構造の例を示します。

• 組織: Payments Division

  • アセット: Payments API - Production
  • アセット: Payments API - Staging
  • アセット: Billing Worker

• 組織: Software Product A

  • アセット: Web Portal
  • アセット: Mobile Backend

さらに、あるものを組織とアセットのどちらで表すべきかを判断するための参考ガイドを以下に示します。

前述のとおり、構造は各組織固有のセキュリティニーズによって異なる場合があります。

組織へのアクセス#

組織にはサイドバーからアクセスできます。サブメニューには、新しい組織を作成するオプションも用意されています。

組織ビュー#

組織のビューには、その状態を一目で把握できるよう、さまざまな表やグラフが含まれています。具体的には以下のとおりです。

• 説明
• キー/重大チェックボックス
  • 「重大」または「キー」にチェックを入れることは、フィルタリング目的にのみ使用されます
• 組織内のアセットのリスト
• 認可されたユーザー(DefectDojoのユーザー)

組織の操作#

組織の作成#

組織を作成する方法は2つあります。

• サイドメニューの組織を追加オプションから
• 全組織一覧の上部にある組織を追加ボタンから

組織の編集#

組織は、組織ビューの説明テーブル右上にあるドロップダウンメニューから編集をクリックすることで編集できます。同じメニューには、全組織一覧で組織の左側にある⋮(縦三点)メニューをクリックしてもアクセスできます。

編集可能な各フィールドは、組織の作成時にも同様に利用できます。

組織の削除#

組織は、組織の設定から組織を削除を選択することで削除できます。

組織は階層の最上位に位置するため、削除するとその下位にあるすべてのセキュリティ履歴、関連性、および子オブジェクトが削除されます。具体的には以下が含まれます。

• 組織内に含まれるすべてのアセット、エンゲージメント、テスト
• 検出事項やインテグレーションを含む、関連するすべてのセキュリティ履歴
• リンクされているすべてのJira Epic
• その組織内のアセット、エンゲージメント、テストに関連するすべてのメモおよびアップロードファイル

組織の削除は元に戻せません。基盤となるデータを削除せずに組織を「廃止」したい場合(たとえば、監査目的でレガシーソフトウェアのテスト記録を保持したい場合など)は、組織の名前を変更するか、非推奨状態であることを示すタグを追加することができます。

組織とメタデータ#

組織は、軽量な分類ではなく、構造的な所有権やレポート境界を表すことを目的としています。デプロイメントの状態、内部ラベル、一時的なワークフロー状態といった属性は、個別の組織として表すよりも、タグやメタデータで表す方が適切な場合があります。

組織の境界#

組織は、DefectDojo内でレポートとアクセスの両方の境界を確立します。インテグレーション、RBAC権限、所有権、メトリクス、重複排除モデルは組織の構造を引き継ぐことが多いため、早い段階で明確な境界を設計しておくことで、後々の階層の肥大化やレポートの断片化を防ぐことができます。

検出事項と自動化#

インテグレーションは通常、アセット、エンゲージメント、検出事項といった下位のオブジェクトで設定されますが、それらのインテグレーションが機能する際の所有権、レポート、アクセスの境界を定義するのは、依然として組織です。

権限は下位に継承されるため、ある組織へのアクセス権を持つと、その組織内のすべてのオブジェクト(アセット、エンゲージメント、テスト、検出事項など)へのアクセス権が自動的に付与されます。

DefectDojoのRBACモデルは、人間のユーザーによるアクセスを制御するために使用できるだけでなく、APIトークンが特定の組織にアクセスできる範囲を制限するためにも使用できます。

ユーザーロールの詳細については、権限の記事を参照してください。

所有権#

組織は最上位のオブジェクトであるため、その内部の子オブジェクトに対する所有権も暗黙的に示します。組織が、その責任を負う担当者を正確に反映するように設定されている場合、SLA追跡、修復ワークフロー、チケットのルーティング、全般的なガバナンスがより円滑に機能します。

メトリクス/レポート#

メトリクスダッシュボード、タイル、ビューは組織ごとにフィルタリングできるため、セキュリティデータの算出、可視化、そして最終的なエクスポートの方法において、組織は重要な役割を果たします。

レポート作成の観点では、一般的に、単一の組織を複数のドキュメントに分割するよりも、複数の組織を1つのドキュメントにまとめる方が簡単です。そのため、チームのレポートに適した粒度で組織を設定することをお勧めします。たとえば、主に大規模な事業部門内の各部署ごとにレポートを作成する予定であれば、その事業部門全体を1つの組織として表す必要はありません。

レポートのニーズを反映するように組織を効果的に構造化することは、セキュリティ体制を正確に評価する上で重要です。メトリクスの詳細については、こちらをクリックしてください。

重複排除#

DefectDojoにおける重複排除はアセットレベルで行われ、親組織の影響を受けません。