流出したのは、社員1人が仕事で使っていたGitHubの認証情報、たった1件でした。WAFの「攻撃遮断くん」や「WafCharm」を提供するサイバーセキュリティクラウド（CSC）は11月12日、その認証情報で入られたとみられるGitHubの領域から、顧客の情報が漏えいしたおそれがあると発表しました。
サービスそのものは止まっていません。CSCによると、12日の時点で、サービスへの不正アクセスや二次被害は見つかっていないといいます。気にかけたいのは別のところです。CSCに個人情報の扱いを任せている会社には、個人情報保護委員会への報告の期限が回ってくるかもしれません。
外からの知らせで気づき、11月5日に確認
きっかけは、外部機関からの情報提供でした。社員が業務で使っていたGitHubの認証情報1件が、外に出ていると分かったのです。CSCがGitHubのアクセスログを調べると、この認証情報を使って第三者が入ったとみられるアクセスが、過去にありました。CSCがそれを確認したのは11月5日。公表はその7日後です。
第一報の「本件の概要と経緯」。外部機関からの情報提供で流出が分かった出典: サイバーセキュリティクラウド「当社開発環境における情報漏えいのおそれに関するお知らせとお詫び（第一報）」(引用)
CSCは「確認可能なアクセスログの対象期間や記録内容には制約がある」とし、認証情報が有効だった期間の全体までは調べきれていないと認めています。
この「制約」は、GitHubに記録が残る期間を知ると見当がつきます。GitHubの説明では、組織の監査ログに出るのは過去180日のイベントです。Enterprise Cloudの監査ログでは、リポジトリの複製を示すgit.cloneのようなGitイベントが、7日間しか残りません。しかもこの種類のイベントは画面に出ず、APIや外部へのストリーミング、書き出しでしか取れないのです。
CSCの場合にどれが当てはまったのかは分かりません。ただ、外から知らされて気づく形だと、知らせが届いた時点で流出から何日たっているかを、自社では選べません。ログを外へ流していなければ、何を持ち出されたかを後から言い切れなくなります。
顧客の連絡先と「通信関連情報」が対象に
漏えいのおそれがある情報として、CSCはGitHubに保存していた次の2つを挙げました。
- 一部の顧客の情報（企業名、氏名、メールアドレスなど）
- サービス利用に伴う通信関連情報
範囲と対象者はまだ調べている途中です。対象と分かった顧客には、順に案内するとしています。顧客から扱いを任されている個人情報については、委託元の顧客と組んで、本人への通知などを進めるといいます。
CSCがすでに済ませた手当ては4つあります。漏れた認証情報の無効化、GitHubに保存されていたほかのサービスの認証情報の確認と変更、関連する認証情報とアクセス権限の見直し、関係する開発端末の隔離とアカウントの利用停止です。
実施済みの対応と、委託元の報告についての記載出典: サイバーセキュリティクラウド「当社開発環境における情報漏えいのおそれに関するお知らせとお詫び（第一報）」(引用)
目が留まったのは2つ目の手当てでした。GitHubに、ほかのサービスの認証情報も置かれていたと読めるからです。1件の認証情報で開いた扉の奥に、別のサービスの鍵の置き場所まであったことになります。
一方で、第一報から読み取れないことも多く残ります。認証情報の種類（パスワードかトークンか）、外に出た時期と経路、「通信関連情報」の中身、GitHubに置かれていた鍵がどのサービスのものか。どれも、まだ発表に書かれていません。
委託元の報告は、知った日を1日目に数える
では、委託元はどう報告すればよいのでしょう。CSCは、委託元の顧客が出す報告について、「連名報告を含めた報告方法についての相談を進めて」いると説明しています。
委員会のガイドラインでは、個人データの扱いを任せている場合、報告の義務は原則として委託元と委託先の双方にあります。両者の連名で出すこともできます。委託先が委託元に事態を通知すれば、委託先の報告義務は免除される仕組みです。CSCの言う「連名」は、この形を指しているとみられます。
期限は2段構えです。速報は、知ってから概ね3〜5日以内。確報は30日以内ですが、不正の目的で行われたおそれがある事態なら60日以内になります。委員会は、不正アクセスで個人データが漏えいした場合を、この「不正の目的」の例に挙げています。法人なら、どこか1つの部署が知った時点を1日目に数え、土日や祝日も含めます。期限の日が休日に当たれば、休日が明けた日に延びます。
実際に数えると、年明けの休みが効いてきます。12日に知った会社なら、60日目は2027年1月10日（日）。13日に知った会社なら、60日目が1月11日の成人の日に当たります。どちらも、確報の期限は1月12日（火）です。
委員会の様式では、報告書に9つの項目が並びます。CSCの第一報と並べると、委託元が自分では埋められない項目が見えてきます。
| 報告書の項目 |
CSCの第一報（11月12日） |
個別の案内で聞くこと |
| 事態の概要 |
外部機関の情報提供で判明し、不審なアクセスを11月5日に確認 |
自社のデータの置き場所と、アクセスがあった期間 |
| 個人データの項目 |
企業名、氏名、メールアドレス等と、通信関連情報 |
自社が任せた情報のうち、どの項目か |
| 本人の数 |
調査中 |
自社が任せた人の数 |
| 発生原因 |
社員のGitHubの認証情報1件の流出（経路は調査中） |
認証情報の種類と、外に出た経路 |
| 二次被害 |
確認されていない |
見つかったときの連絡の手順 |
| 本人への対応 |
委託元と連携して通知などを進める |
通知を出す名義と文面 |
| 公表 |
11月12日に公表 |
自社でも公表するか |
| 再発防止の措置 |
認証情報の無効化など4つを実施済み。管理体制などの見直しは実施中 |
見直しの中身と終わる時期 |
| その他 |
外部の専門機関とフォレンジック調査 |
調査の報告書を受け取れるか |
中の列を埋めているのは、ほとんどがCSC全体の話です。自社の項目と人数が分からないまま期限が来たら、分かっている範囲で確報を出し、判明しだい追って報告することになります。右の列をまとめて一度に聞いておけば、年末の慌ただしい時期に何度も問い合わせずに済むはずです。
影響を受けるのは、個人情報の扱いを任せた会社
いちばん影響が大きいのは、CSCのサービスで個人情報の扱いを任せている会社です。委員会への報告と、本人への通知の当事者になりえます。ただ、どのサービスで預かった情報なのかは、第一報に出ていません。
CSCと取引があり、担当者の名前やメールアドレスを伝えている会社も、対象に入るかもしれません。こちらは担当者本人の連絡先の話です。CSCを名乗るメールにリンクや添付が付いてきたら、契約の窓口に別の経路で問い合わせてから開くよう、担当者に伝えておけば足ります。
CSCと契約も取引もない会社には、関係のない話です。WAFなどの防御が止まったわけでもありません。CSCは12日の時点で、サービスの提供やセキュリティ機能への影響を確認していないとしています。今の段階で、WAFを外したり乗り換えたりする理由にはならないとみています。それでも比べ直したいときは、WAFの製品の地図で、料金の数え方や運用を任せる範囲を見比べられます。
自社のGitHubで今日確認すること
流出した認証情報の種類は発表されていません。トークンだった場合は、どの会社のGitHubにもある初期設定が関わってきます。GitHubの説明では、組織の初期設定のままだと、classicの個人用アクセストークンで組織のリソースに入れます。classicのトークンには有効期限の決まりがありません。fine-grainedのトークンは管理者の承認が既定で要りますが、組織が認める最長の有効期間は既定で366日です。
組織のオーナーなら、ここを変えられます。classicのトークンで組織のリソースに入れなくする。有効期間の上限を短くする。どちらも組織の設定画面で選べます。
- CSCの案内がどの部署に届くかを調べ、届いた日を法務や個人情報の担当に伝える経路を決めます。12日に公表を見て知ったなら、速報の目安の3〜5日は今週末から来週の初めです。CSCに任せている個人情報も、サービス名と項目、おおよその人数で書き出しておきます。
- GitHubの組織の設定で、classicのトークンを組織のリソースに使わせているかを見ます。使わせるなら、有効期間の上限を決めます。
- リポジトリに、ほかのサービスのキーやパスワードが置かれていないかを探します。CSCが替えたのも、GitHubに置かれていたほかのサービスの認証情報でした。
- GitHub Enterprise Cloudを使っているなら、監査ログを外部に流しているかを見ます。流していなければ、あとで調べられる範囲は180日分のイベントと、7日分のGitイベントまでです。
- 「御社の認証情報が外に出ている」と外部から知らされたときに、だれが受け、その日のうちにどのログを見るかを決めておきます。
外部機関から連絡を受けた日を、CSCは明かしていません。はっきりしているのは、不審なアクセスを確認してから公表まで7日だったことです。自社に同じ連絡が来た日、手元のログは何日前までさかのぼれますか。答えが「7日」なら、ストリーミングの設定は今週のうちに済ませておく価値があります。
