SOC 2などの監査では、資産の一覧が範囲に含まれることが多く、脆弱性への対応も重要なコントロールとされています。Drataでは、連携先から資産と脆弱性を取り込み、資産の一覧と脆弱性の対応の期限を1つの画面で管理できます。このページでは、Drataでの資産と脆弱性の管理として、連携で自動的に集まる資産と手動で登録する資産、資産台帳としての使い方、脆弱性の深刻度と対応期限の設定を説明します。
資産の一覧（Asset Inventory）
資産の一覧（Asset Inventory）は、コンプライアンスと監査の対象になる資産を記録するDrataの台帳です。資産には、コントロールを支えるシステム、ツール、文書、人が含まれます。Drataは資産の一覧を、コントロールの範囲、テストの準備状況、監査の証跡の評価に使います。
資産の一覧は、Risk → Assetsで開きます。資産の一覧では、次のことができます。
- 資産の分類（
Class）、種類（Type）、取得元（Source）、オーナー（Owner）、オーナーの状態（Owner status）で絞り込む - 資産の名前で検索する
- 監査のレビューのために、資産の一覧をダウンロードする
資産の種類は、物理的な資産（Physical）と仮想の資産（Virtual）の2つです。資産の分類には、ハードウェア、文書、要員、ソフトウェア、コード、コンテナ、コンピューティング、ネットワーク、データベース、ストレージがあります。
連携で自動的に集まる資産
クラウド基盤やMDMなどと連携すると、資産が自動で取り込まれます。
| 連携先 | 取り込まれる資産 | オーナーの決まり方 |
|---|---|---|
| AWS | ECS、EKS、RDS、ECR、WAF、CloudFront、CloudTrail、EC2、S3の資源。分類はストレージ、コンテナ、コンピューティング、データベース、ネットワーク | 主要な担当者（Key personnel）のEngineering Lead。いなければCEO、主要な担当者が設定されていなければ最初のAdmin |
| Microsoft Azure | Azure Virtual Machines、Azure Kubernetes Service、Azure Blob Storage、SQL Databaseなど12のサービス。毎日同期される | Azureで資産に割り当てた所有者。いなければサブスクリプションの所有者のうち在籍中の要員、見つからなければ連携を作ったユーザー、それもいなければ最初のAdmin |
| Google Cloud | Google Compute Engine、Cloud Run、GKE、Cloud Storage、Cloud SQLなど8つのサービス。毎日同期される | Google Cloudで資産に設定された所有者のうち在籍中の要員。見つからなければ最初のAdmin |
| MDMとDrata Agent | 社員の端末 | 端末に割り当てられた要員 |
クラウドから取り込んだ資産の種類は、常に仮想の資産です。Google Cloudの資産を取り込むには、DrataのサービスアカウントにCloud Asset Inventory APIの権限が必要です。主要な担当者の設定は、組織の情報と主要な担当者で説明しています。
監査の範囲に含まれないクラウドの資源は、除外のタグで取り込みから外します。AWSとMicrosoft AzureではタグのキーをDrataExclude、Google Cloudではラベルをdrataexcludeにします。
| タグを付けた時点 | 動き |
|---|---|
| 資産が同期された後 | 次の同期で、その資産のDeleted Onの列に日時が記録される |
| 資産が初めて同期される前 | その資産は取り込まれない |
クラウド基盤との連携と除外のタグはクラウド基盤との連携、端末の取り込みはMDMで端末の状態を集めるで説明しています。
手動で登録する資産
連携で自動的に見つからない資産は、手動で登録します。手動で登録した資産も、テストと監査では自動的に見つかった資産と同じように扱われます。
Risk→Assetsを開きます。Create assetを選びます。- 必要な項目を入れて、保存します。
資産を一括で登録、更新する
多くの資産をまとめて登録する場合や、ほかのGRCのツールから移す場合、棚卸しの後にまとめて更新する場合は、一括インポートを使います。CSVファイルのアップロードのほか、画面のシートに直接入力することもできます。
Risk→Assetsで、右上のCreate assetの横の矢印を選び、Create/update assets in bulkを選びます。Upload fileでCSVファイルをアップロードするか、Manually enter dataでシートに入力します。- ファイルをアップロードした場合は、ファイルの列をDrataの項目に対応付け、
Continueを選びます。選択肢のある項目は、値の対応付けもできます（任意）。 - シートで検証の結果を確かめます。赤いセルはエラーで、直すまで送信できません。黄色いセルは警告で、そのまま送信できます。
Download validation resultsで、エラーの一覧をCSVで書き出せます。 Submitを選び、作成と更新の件数を確かめて、Import assetsを選びます。
Assetsページ。Create assetの横の矢印から、資産を一括で作成、更新するメニューを開く
| 項目 | 必須 | 内容 |
|---|---|---|
Asset Name | ○ | 資産の名前。191文字まで。既にある資産との照合に使う（大文字と小文字を区別しない） |
Asset Type | ○ | PHYSICALかVIRTUAL |
Asset Class Types | ○ | HARDWARE、DOCUMENT、PERSONNEL、SOFTWARE、CODE、CONTAINER、COMPUTE、NETWORKING、DATABASE、STORAGEから1つ以上 |
Description | ○ | 資産の短い説明。191文字まで |
Unique ID | ― | 資産タグやシリアル番号などの識別子 |
Owner Email | ○ | 資産のオーナーのメールアドレス。在籍中の要員（社員か業務委託者）である必要がある |
Notes | ― | 補足のメモ。191文字まで |
名前が既にある資産と一致した場合は、その資産の取得元によって扱いが変わります。
| 既にある資産 | 扱い |
|---|---|
| ない（新しい名前） | 新しい資産として作られる |
| 手動で登録した資産 | その資産が更新される。資産の分類は、ファイルの値で全て置き換えられる |
| 連携で取り込まれた資産（AWS、Jamf、Oktaなど） | 取り込めない。連携先で管理する |
一括インポートのメニューは、Bulk Import Asset — Manageの権限を持つユーザーに表示されます。この権限は、既定ではAdminやInformation Security Leadなどのロールに付いています。
【注意】 資産のオーナーは、取り込む時点で在籍中の要員である必要があります。退職した人や在籍していない人を指定した行はエラーになります。新しく入った人をオーナーにする場合は、先にIDプロバイダーとの同期で要員として取り込んでから、資産を取り込み直します。
資産台帳としての使い方
Risk Assessment Policyのテンプレートでは、リスクアセスメントの最初の段階として、情報セキュリティーの範囲に含まれる全ての資産を洗い出し、資産ごとにオーナーを決めることとしています。資産の一覧を資産台帳として使うときは、次の点を押さえます。
| 押さえる点 | 方法 |
|---|---|
| オーナーを決める | 全ての資産にオーナーを割り当てる。Owner statusの絞り込みで、オーナーの状態を確かめる |
| 補足を残す | 資産のメモ（Asset Notes）に、責任の所在、例外や補足、監査向けの説明を書く。資産を選んで追加、更新する |
| 範囲を合わせる | 監査の範囲に含まれないクラウドの資源には、除外のタグを付ける |
| 端末を整理する | 廃棄した、なくした、別の人に渡した端末は、要員との対応付けを外す。外した端末は、AssetsページとPersonnelページから消える |
| 監査に出す | 資産の一覧をダウンロードして、監査のレビューに使う |
端末の管理元がDrata AgentからMDMに変わっただけで、同じシリアル番号の端末を同じ人が使い続けている場合は、対応付けを外す必要はありません。次の同期で取得元が自動で更新されます。
脆弱性の管理
Vulnerabilitiesページは、連携したツールで見つかったセキュリティーの脆弱性をまとめるページです。是正の優先順位を付け、SLA（対応の期限）を追い、コンプライアンスの状態を確かめられます。脆弱性を取り込むには、少なくとも1つの脆弱性スキャンの製品と連携する必要があります。連携できる製品はMDMとセキュリティー製品との連携で説明しています。
脆弱性はRisk → Vulnerabilitiesで開きます。このページでは、次のことができます。
- 連携先、深刻度、期限、修正の有無で絞り込む
- 脆弱性のIDで検索する
- SLAの期限と、今の状態を確かめる
- 脆弱性の報告書（絞り込んだ分か、全て）をダウンロードする
Resyncでデータを同期し直す
脆弱性を選ぶと、CVSSのスコア、深刻度、SLAの期限、状態、連携先のツールの情報などの詳細が表示されます。Drataは、脆弱性をリソースごとの検出事項として数えるため、連携先の画面より件数が多く見えることがあります。
【注意】 Drataは脆弱性を直しません。状態、期限、コンプライアンスへの影響を追う仕組みで、是正は連携先のツールで行います。
深刻度と対応期限
Drataは、脆弱性の深刻度ごとにSLAの期限を計算します。脆弱性の管理のポリシーがない場合は、次の既定の期限を使います。
| 深刻度 | 既定の期限 |
|---|---|
| Critical | 7日 |
| High | 30日 |
| Medium | 90日 |
| Low | 180日 |
脆弱性の管理のポリシー（Vulnerability Management Policy）がある場合は、ポリシーで決めたSLAを使います。SLAの期限は、VulnerabilitiesページのSLA Due Dateの列に表示されます。ポリシーのSLAの設定は、ポリシーテンプレートを自社の規程に合わせるで説明しています。
SLAと事前の通知の期間は、次の手順で変えられます。
Risk→Vulnerabilities settingsを開きます。SLA Settingsで、深刻度ごとのSLAの値を編集します。- 期限が近づいたことを知らせる期間（warning period）を決めます。例えば7日にすると、各SLAの期限の7日前に通知が送られます。
SLAを過ぎた脆弱性や期限が近い脆弱性をメールで受け取るには、Settings → NotificationsでReminders for vulnerabilities with missed or upcoming SLAsを有効にし、受け取る頻度を選びます。通知には、深刻度がCriticalとHighの脆弱性の要約と期限が含まれます。詳しくは通知の設定で説明しています。
脆弱性のモニタリングテスト
Drataは、連携先ごとに次のモニタリングテストを作ります。
| テスト | 失敗する条件 |
|---|---|
Critical Vulnerabilities Addressed – <連携先の名前> | 深刻度がCriticalの脆弱性が1つ以上残っている |
High Vulnerabilities Addressed – <連携先の名前> | 深刻度がHighの脆弱性が1つ以上残っている |
これらのテストは、四半期ごとの脆弱性スキャンのコントロールの一部です。このコントロールは、方針と要件に従って本番環境の脆弱性スキャンを行い、スキャンの結果を管理者がレビューし、優先度の高い検出事項を解決まで追うことを求めています。
テストが失敗したら、残っている脆弱性を連携先のツールで是正するか、テストの結果の画面で除外します。除外の使い方は、除外と無効化の使い分けで説明しています。SLAを正しく保ち、連携を有効に保ち、脆弱性を解決しておくことで、テストが成功し、SLAの約束を守り、監査の証跡の裏付けが保たれます。