プレビュー版
このガイドはプレビュー版です。内容は今後変わることがあります。
計画② 体制と見える範囲を決める#
全員が読む
FutureVuls を使う人と、それぞれが見られる範囲を決めます。ここで決めた内容が、次の設定① アカウントの構造をつくるで作成するグループの分け方になります。
決めておく6つのこと#
| # | 決めること | 決め方の例 | 導入準備シートの書き込み先 |
|---|---|---|---|
| 1 | 運用の中心になる方と、意思決定をする方 | 毎日の確認をする方と、対応方針を決める方を1人ずつ決めます | 運用の中心になる方・意思決定をする方 |
| 2 | アカウントを発行する人 | 部署と名前、役割を書き出します。全グループをまたいで見る方（全社の取りまとめ役など）がいれば、あわせて書きます | アカウントを発行する人（B-7） |
| 3 | 脆弱性への対応を誰に頼むか | 「システムごとに担当者が決まっている」「サーバの種類ごとに分かれている」「部署単位で決まる」など、今の決まり方を書きます | 対応の依頼先の決まり方（B-8） |
| 4 | 各部署が見られる範囲 | 「部署ごとに自部署のサーバだけを見せる」「全員が全体を見られる」など | 各部署が見られる範囲（B-9） |
| 5 | 対応の管理に使うツール | FutureVuls のタスクだけで管理するか、Jira や Redmine などほかのツールでも管理するか | 対応の管理方法（B-10）、外部のチケット管理 |
| 6 | お知らせの届け先 | グループごとに担当者へ届けるか、代表のメーリングリストにまとめるか。Slack や Teams に届けるか | お知らせの届け先（B-15、C-11） |
グループの分け方の考え方#
FutureVuls では、見られる範囲と、毎日の対応の単位が「グループ」です。上の3と4で決めた内容から、次の順で考えると決めやすくなります。
- 見せたくない範囲で分ける：ほかの部署に見せたくないサーバは、別のグループにします。
- システムで分ける：同じシステムを構成するサーバを、1つのグループにまとめます。システム単位で分けるのがおすすめです。
- 迷ったら少なめに：グループは後から分けられます。最初は少なめにして、運用しながら分けるのがおすすめです。サーバは、あとから別のグループへ移動できます（サーバ情報を他グループへ移動）。移動には、移動元と移動先の両方のグループ管理者の権限が必要です。移動した月は、移動元と移動先の両方のサーバが課金の対象になります。
全社や部門をまたいで状況をまとめて見たい場合は、複数のグループを「グループセット」でまとめます。グループセットは CSIRT プランの機能です（グループセット設定）。1つのグループは、複数のグループセットに入れられます。
flowchart TB
O["オーガニゼーション（全社で1つ）"] --> S1["グループセット：本番システム"]
O --> S2["グループセット：公開系サーバ"]
S1 --> G1["グループ：情報システム"]
S1 --> G2["グループ：生産管理"]
S1 --> G3["グループ：公開Web"]
S2 -.-> G3ほかのツールで対応を管理している場合#
Jira や Redmine などで脆弱性への対応を管理している場合は、FutureVuls のタスクと二重管理にならないよう、どちらで何を管理するかを先に決めておきます。FutureVuls 上でタスクのステータスを更新しないと、「対応が進んでいるか」を FutureVuls で確認できなくなります。
併用する場合の標準は、「検知と判断（ステータス）は FutureVuls に記録し、作業の進め方は外部ツールで管理する」形です。少なくとも FutureVuls のステータスだけは更新するようにしておくと、対応の状況を FutureVuls で把握できます。外部ツールとの連携には、API（FutureVuls API）や CSV レポートが使えます。
つまずいたとき#
- 権限やログインの設定がわからない：権限・ロールとログインの設定
- グループやオーガニゼーションの設定がわからない：グループ・オーガニゼーションの設定
それでも解決しない場合は、お問い合わせ窓口からご連絡ください。
次に読むページ#
対象のサーバの環境を確認します。計画③ 環境を確認するに進みます。