Tsuzura

Guide

突然社内システム担当になったら最初に棚卸しするもの

引継ぎ不足の新任システム担当者が、記事独自の24時間・1週間・30日の目安で、重要業務、アカウント、契約、データ、バックアップ、外部事業者を確認する。

突然、社内システムの担当になったら、すぐに設定を変えるより先に、誰が判断するのか、どの業務が止まると困るのか、緊急時は誰へ連絡するのかを確かめます。その後、管理アカウント、契約、データ、バックアップと復元、外部事業者の情報を優先順に台帳へまとめます。

十分な引き継ぎがないまま社内ITを任された人を対象にしています。経営責任者、業務責任者、前任者または外部事業者へ連絡できることが前提です。24時間・1週間・30日は、編集部が整理した作業の目安であり、法定期限ではありません。個別インシデントへの対処、正規の承認を得ない権限取得、セキュリティ監査に合格したという保証は扱いません。

今まさに障害や漏えいが疑われる場合

業務が止まっている場合や、データ消失・漏えい・不正アクセスが疑われる場合は、棚卸しより社内の緊急手順と連絡先を優先します。判断責任者と技術担当へ、発生時刻、症状、影響範囲、直前の変更を伝えます。指示が出るまでは、設定変更やログ削除など状態を変える操作を控えます。

本記事は個別のインシデント対応手順ではありません。後半の「インシデント連絡を確認する」で連絡経路を確認し、必要に応じて外部事業者や専門責任者へ引き継ぎます。

先に「触らない条件」を決める

次のいずれかが分からないときは変更を止め、責任者へ判断を求めます。

  • そのシステムが止まった場合の影響
  • 変更を承認する業務責任者
  • 現在の管理者と正規の権限取得手順
  • バックアップの対象と最後の復元テスト
  • 切り戻しまたは手動代替
  • 外部事業者の緊急連絡先
  • 契約・法令上の報告や制約

パスワードを推測したり、共有アカウントを奪ったり、利用者を一括削除したりしません。まず会社の承認と証跡を確保します。

用語や影響が分からない項目は、推測で埋めません。「未確認」と書き、確認先と期限を付けます。用語を調べたことと、作業の承認を得たことは別です。

IPAの中小企業の情報セキュリティ対策ガイドライン第4.0版は、情報セキュリティを担当者へ任せきりにせず、経営者が方針を示し、担当者を任命して指示する必要があると説明しています。新任担当者一人へ責任を集めず、経営側に判断を求められる経路を作ります。

最初の24時間

1. 緊急連絡先を1枚にする

経営責任者:
業務責任者:
技術担当:
副担当:
緊急時の代理者:
セキュリティ・個人情報保護:
法務・総務:
主要外部事業者:
ホスティング・ネットワーク:
連絡手段:
時間外連絡:
判断できる範囲:

通常のメールやチャットが止まった場合に備え、電話などの別経路も確認します。

2. 止まると困る業務を聞く

システム名から考えるのではなく、給与、受注、出荷、請求、顧客対応、アカウントへのログインなど、期限があり、止まったときの影響が大きい業務を聞きます。

業務 期限 利用システム 止まった影響 手動代替 責任者
例:請求 月末 会計SaaS 請求遅延 CSV作成 経理責任者

「重要」の基準は利用者数だけではありません。少人数でも支払、法定手続、顧客データへ関わるシステムは優先します。

3. 重大な期限切れだけ確認する

  • ドメインとTLS証明書
  • クラウド・SaaSの契約更新
  • ライセンス
  • バックアップ処理の失敗
  • 管理者退職予定
  • 支払方法
  • 保守契約
  • 公開済みの障害・セキュリティ警告

まず期限と状態だけを確認します。影響が分からない自動更新や一括変更は保留です。

最初の1週間:最小台帳を作る

同じIPAガイドラインの資産管理では、機器、基本ソフト(OS)、ソフトウェア、ネットワーク、設置場所や構成、保守を担う外部事業者などを把握する項目が示されています。最初からすべてを網羅せず、止まったときの影響が大きい対象から台帳を作ります。

資産区分(システム / 機器 / 契約):
システム・機器名:
メーカー・型番 / 資産管理番号:
支える業務:
重要度:
URL・設置場所:
利用者・設置部署:
業務責任者:
変更・停止手順の承認者:
変更・停止手順の実行者:
変更・停止手順の立会者:
変更・停止手順の中止条件:
切り戻し方法:
副担当:
緊急時の代理者:
管理アカウント:
認証・回復方法の保管場所:
データの種類・所在:
連携先:
契約・更新日:
保守・保証期限:
外部事業者・連絡先:
問い合わせ窓口:
監視:
バックアップ:
最後の復元テスト:
手動代替:
変更・停止手順:
最終確認日:

責任者、承認者、実行者は役割が違うため、同じ人が兼ねる場合も欄を分けます。副担当や緊急時の代理者が決まっていなければ、「未選任」と記録し、選ぶ責任者と期限を付けます。

設定変更や停止手順も、新任担当者が単独で試す対象ではありません。承認者と実行者、立会者を決めます。中止条件と切り戻し方法まで分からなければ、実行を保留します。

PC、サーバー、ルーター、バックアップ機器も台帳の対象です。すべてを一度に数えず、重要業務で使う機器、管理用端末、ネットワーク機器から確認します。

SaaS、API、ドメイン、DNS、TLS証明書、ソースコードの保管場所、CI/CD、端末管理もシステム欄へ含めます。SaaSはインターネット経由で使うソフトウェア、APIはシステム同士をつなぐ窓口です。DNSはドメイン名の接続先を管理し、TLS証明書は暗号化通信の相手を確かめるために使われます。CI/CDはビルドや配布を自動化する仕組みです。意味や利用状況が分からないものは「未確認」とし、確認先と期限を残します。

問い合わせを一か所に集める

個人宛てのメールや口頭依頼だけで受けず、専用メール、フォーム、共有表など、社内で使える受付先を一つ決めます。問い合わせを同じ場所へ集めると、対応状況と棚卸しに使える時間を分けて管理できます。

受付日時:
依頼者・連絡先:
対象業務・システム:
症状・依頼内容:
業務は止まっているか:
希望期限:
影響を受ける人:
優先度:
担当者:
対応記録:
現在の状態:
次の連絡日時:

優先度は、まず「緊急」「期限あり」「通常」の三つに分けます。重要業務の停止や漏えい等の疑いは「緊急」とし、すぐ責任者へ引き継ぎます。業務を続けられても締切へ影響するものは「期限あり」です。それ以外の質問や改善要望は「通常」としてまとめて扱えます。

この区分は問い合わせ整理の例であり、法令や契約の報告期限ではありません。報告の要否と期限は、社内規程、契約、後半で案内する個人情報保護委員会等の現行資料で確認します。

アカウントと秘密情報

同じIPAガイドラインは、利用者IDと管理者IDを発行・変更・削除まで管理し、権限を必要最小限にするよう示しています。共有IDは避け、例外として使う場合も、誰が利用したか追える形にします。

台帳にパスワードや秘密鍵そのものを平文で書きません。記録するのは次です。

  • アカウント名と役割
  • 責任者
  • 権限の強さ
  • 多要素認証(MFA)
  • 回復手段
  • 秘密情報の管理ツールなどの保管場所
  • 最終確認日
  • 退職・異動時の回収手順

root(最高権限)や組織管理者のアカウントが退職者だけにひも付いている場合は、経営責任者の承認を得て、提供事業者の正規サポートから回復手続きを進めます。

データの所在と責任者

重要なデータ群ごとに、種類、機密区分、保存場所、責任者、取得元を記録します。

データ群 正本 責任者 個人・機密 バックアップ 保持・削除
顧客マスター 顧客管理システム(CRM) 営業責任者 個人情報あり 日次 方針確認
請求データ 会計SaaS 経理責任者 機密 書き出し確認 法務確認

全ファイルを一覧にするより、失うと業務が止まるデータ群から始めます。生成AIへ入力するデータがある場合は、入力データの判断手順も確認します。

バックアップと復元を分ける

「バックアップあり」という回答だけでは終えません。

対象:
方式:
頻度:
保管場所:
世代数:
保持期間:
暗号化・アクセス権:
監視:
テスト承認者:
実行者:
立会者:
テスト環境・データ:
復元先:
中止条件:
切り戻し方法:
必要な復旧時間:
許容できるデータ損失:
最後に復元した日:
結果:

NIST CSF 2.0は、バックアップを保護・保守・テストし、復元前後のデータの完全性を確認する成果を示しています。IPAガイドラインでも、取得対象、頻度、保管、復旧計画、実際に復元できるかどうかが確認項目になっています。

新任担当者が単独で復元テストを実行する想定ではありません。業務責任者がテストを承認し、必要な権限と経験を持つ技術担当者または外部事業者が実行します。新任担当者は日程調整と記録、連絡を担えます。

テスト前に立会者を決めます。隔離した復元先と使うデータ、中止条件、切り戻し方法も確認します。一つでも分からなければ実行せず、「未確認」と確認先と期限を台帳へ残します。必要な復旧時間と許容できるデータ損失は、業務責任者と合意します。

外部事業者と契約の責任分界

外部事業者ごとに次を確認します。

  • 契約責任者と更新日
  • サポート時間と緊急連絡
  • 障害・漏えい時の通知
  • 自社と外部事業者の作業範囲
  • 外部事業者が持つアカウントと権限
  • 再委託先
  • ログと証跡
  • 契約終了時のアカウント停止
  • データの書き出しと削除
  • ソースコード、ドメイン、鍵、文書の所有

NIST SP 800-61r3は、第三者がインシデント対応を担う場合も、情報の流れ、調整方法、第三者が行使できる権限と制限を明確にするよう案内しています。本記事ではこの米国の任意ガイドを責任分界の参考に限り、日本の法定報告義務の根拠には使いません。

契約の意味は法務・購買責任者へ確認します。台帳に書いただけで、責任分界が相手と合意済みになるわけではありません。

インシデント連絡を確認する

IPAガイドラインは、インシデントの対象と重大度、判定基準、責任者へ判断を求める流れ、役割、報告事項、連絡体制を決めておくことを扱っています。

検知した人:
一次連絡:
判断責任者:
技術対応:
利用者連絡:
法務・個人情報保護:
外部事業者:
記録場所:
業務継続:
復旧承認:
振り返り:

個人データの漏えい等については、個人情報保護委員会の漏えい等対応の案内で、報告対象、期限、報告先を確認します。ほかのデータ、業種、インシデントには別の法令・契約・規則が適用される場合があるため、専門責任者へ確認してください。

編集部の目安:30日以内に引き継ぎを直す

  1. 台帳の空欄へ責任者と期限を付ける
  2. 管理アカウントを個人依存から回復可能にする
  3. 契約と更新通知を共有する
  4. 復元テストの承認者、実行者、立会者、中止条件を記録する
  5. 重要システムの監視と通知の担当者を決める
  6. 手動代替と停止手順の承認者、実行者、立会者、中止条件を決める
  7. 外部事業者の責任分界を確認する
  8. 副担当も読める運用手順書を作る
  9. 問い合わせの受付先、優先度、記録場所を決める
  10. 四半期等の見直し日を決める

新しいシステムを買うか作るかは、現在の責任者、データ、利用終了時の移行方法を把握してから、作る・買う・やめる判断表で比べます。サービスの公開・監視・復旧までを考えるときは、Webサービス開発ロードマップへ進めます。

完了の目安

棚卸しが終わっても、「すべて安全」と保証されたわけではありません。重要システムごとに、責任者、管理者アクセス、契約、データ、バックアップと復元、連絡先、停止・復旧手段が分かり、残った不明点にも担当者と期限が付いている状態です。まずは、そこまで見える状態を目指します。