組織 (Pro)

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

概要#

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

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

上記の例に共通するテーマは、組織の本質的な有用性を示しています。すなわち、組織は一般的に、セキュリティプログラム内で安定した長期的な境界を表すべきだということです。

組織のデータと構造#

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

組織を作成する際は、その構造がレポート作成にどのように影響するかを考慮してください。組織に、その組織が含むプロジェクト(アセット)に取り組むチームを表現させたいのか。それとも、組織にその中に含まれるプロジェクト(アセット)のさまざまなバージョンを包含する、より包括的なプロジェクトを表現させる方が適しているのか。

特定の事業領域や開発チームに関連するすべての情報を含む単一の組織がある場合、それを1つの組織として表現することで、さまざまなアセットや組織からレポートをまとめ上げる必要がなくなり、よりスムーズなレポート作成が可能になります。

特定のソフトウェアプロジェクトに多数の異なるデプロイやバージョンがある場合、そのプロジェクト全体のスコープをカバーする単一の組織を作成し、各バージョンを個別のアセットとして存在させる方が良い場合もあります。ワークフローによっては、ソフトウェアのライフサイクルの段階を区別するために組織を使用することもあります。例えば、「開発中」用の組織と「本番稼働中」用の組織を分けるといった具合です。 ​ 組織は、RBAC(ロールベースアクセス制御)の目的で、子会社、買収した企業、その他の規制対象事業単位へのアクセスを決定するために使用できます。異なるアクセスルールを持つ独自のプロジェクトが多数存在する複雑な事業においては、組織の設計が特に重要になります。

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

以下に、オブジェクトを組織とアセットのどちらに指定するかを判断する際の参考となる、いくつかの構造例を示します。

• 組織: 決済部門

  • アセット: 決済API - 本番環境
  • アセット: 決済API - ステージング環境
  • アセット: 請求ワーカー

• 組織: ソフトウェア製品A

  • アセット: Webポータル
  • アセット: モバイルバックエンド

さらに、あるものを組織とアセットのどちらで表現するのが適切かを示す参考ガイドは以下の通りです。

前述の通り、構造は自社独自のセキュリティニーズによって異なる場合があります。

組織へのアクセス#

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

組織ビュー#

組織のビューには、そのステータスを一目で把握できるよう、さまざまなテーブルとチャートが含まれています。これには以下が含まれます。

• 説明
• コマース
  • 組織がCriticalまたはKeyに指定されているかどうか
    • CriticalまたはKeyのチェックは、フィルタリング目的でのみ使用されます
• 割り当てられたメンバー (DefectDojoユーザー)
• 割り当てられたユーザーグループ
  • 権限制御のために組織に割り当てられたユーザーグループ。ユーザーグループの詳細はこちらをご覧ください。
• 組織内のアセットの一覧

組織の操作#

組織の作成#

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

• サイドメニューの新規組織オプションから
• すべての組織の一覧の上部にある新規組織ボタンから

組織の編集#

組織は、組織ビューの右上にある歯車メニューから組織を編集をクリックすることで編集できます。同じメニューには、すべての組織のビューで組織の左側にある⋮ケバブメニューをクリックすることでもアクセスできます。

編集可能なすべての項目は、組織の作成時にも利用できます。

組織の削除#

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

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

• その組織に含まれるすべてのアセット、エンゲージメント、テスト
• 検出事項や統合を含む、関連するすべてのセキュリティ履歴
• リンクされたすべてのJiraエピック
• その組織内のアセット、エンゲージメント、テストに関連付けられたすべてのメモとファイルアップロード

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

組織とメタデータ#

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

組織の境界#

組織は、DefectDojo内でレポートとアクセスの両方の境界を確立します。統合、RBAC権限、所有権、メトリクス、重複排除モデルは組織の構造を継承することが多いため、早い段階で明確な境界を設計しておくことで、後になって階層が肥大化したりレポートが断片化したりすることを避けられます。

検出事項と自動化#

統合は通常、アセット、エンゲージメント、検出事項などの下位のオブジェクトで設定されますが、それらの統合が動作する範囲となる所有権、レポート、アクセスの境界を定めるのは、依然として組織です。

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

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

ユーザーロールの詳細については、権限タイプの概要の記事をご覧ください。

所有権#

最上位のオブジェクトとして、組織はその中の子オブジェクトに対する所有権も意味します。組織がその責任者を正確に反映するように設定されていると、SLAの追跡、修復ワークフロー、チケットのルーティング、全般的なガバナンスがよりスムーズに機能します。

メトリクス/レポート#

メトリクスダッシュボード、タイル、ビューは組織ごとにフィルタリングできるため、セキュリティデータがどのように計算、可視化され、最終的にエクスポートされるかを左右する重要な要素となります。

レポート作成の観点では、一般的に、単一の組織を複数の文書に分割するよりも、複数の組織を1つの文書にまとめる方が容易です。そのため、チームのレポートにとって意味のある粒度で組織を設定することを推奨します。例えば、主にその事業部門内の個々の部門に対してレポートを作成する予定であれば、大きな事業部門全体を1つの組織として表現する必要はありません。

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

重複排除#

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