0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

GitHub・Slack や 仕事アカウント には MFA やパスキーが必須 : 乗っ取り対策

0
Posted at

GitHub、Slack、Google Workspace、Microsoft 365 など、仕事で使うアカウントは増える一方です。
しかも、これらは単なる連絡手段ではなく、コード、チャット、ファイル、顧客情報、社内情報への入口にもなっています。

そのため、これらのアカウントが1つでも乗っ取られると、被害はそのサービス単体で終わらないことがあります。

  • GitHub が乗っ取られる
  • Slack が乗っ取られる
  • 仕事用メールが乗っ取られる
  • そこから他サービスのパスワード再発行や内部連絡のなりすましにつながる

という流れは、十分に現実的です。

だからこそ、GitHub・Slack・仕事アカウントには、少なくとも MFA、できればパスキーを使う という前提で考えた方がよいと思います。


先に結論

結論はシンプルです。

  • 仕事で使うアカウントにパスワードだけは危険
  • まずは MFA を有効にする
  • 可能ならパスキーを優先する
  • 復旧手段も同時に整える
  • GitHub・Slack・メールの3つは特に優先度が高い

「まだ自分は狙われないだろう」と思いがちですが、実際には
特定の個人が狙われるというより、ログイン情報の使い回しやフィッシング、セッション奪取、設定不備 の方が起きやすいです。

つまり、派手な攻撃を想定する前に、まずは基本の認証強化をやるべきです。


なぜ GitHub・Slack・仕事アカウントが危ないのか

これらのアカウントは、どれも「次の被害の踏み台」になりやすいからです。

GitHub

GitHub には、ソースコード、Actions、Secrets、デプロイ設定、運用情報が入っていることがあります。
個人開発でも、リポジトリだけでなく、APIキーやクラウドとの接点を持っていることがあります。

Slack

Slack は単なるチャットではありません。

  • 社内の相談内容
  • 顧客名
  • 障害情報
  • URL
  • 招待リンク
  • 運用フロー

など、かなり多くの情報が流れます。

もし Slack が乗っ取られると、情報閲覧だけでなく、本人になりすました投稿 も問題になります。

仕事用メールや Google / Microsoft 系アカウント

メールは特に危険です。
なぜなら、多くのサービスのパスワード再設定先になっているからです。

つまり、メールアカウントが破られると、そこから他サービスまで連鎖することがあります。


パスワードだけでは足りない理由

「長くて複雑なパスワードを使っているから大丈夫」と思いたくなりますが、パスワードだけでは防ぎきれない場面があります。

たとえば、

  • フィッシングサイトに入力してしまう
  • 他サイト由来の漏えいパスワードを使い回している
  • 認証情報をうっかり保存・共有してしまう
  • 本物に見える偽ログイン画面にだまされる

といったケースです。

このとき、パスワードだけだと一発で終わることがあります。
だから、2段階目の確認である MFA が必要になります。


まずは MFA を有効にする

最初の一歩として、MFA(二要素認証)を有効化するのは必須です。

MFA を入れると、仮にパスワードが漏れても、追加の認証が必要になります。
これだけでも防げる事故はかなりあります。

特に優先したいのは次の3つです。

  • GitHub
  • Slack
  • 仕事用メール / Google / Microsoft 系アカウント

この3つを後回しにする理由はありません。


ただし SMS より、認証アプリやパスキーの方がよい

MFA といっても方法はいろいろあります。

  • SMS
  • 認証アプリ
  • ハードウェアキー
  • パスキー

この中で、SMS は「何もしないよりはよい」けれど最優先ではない という位置づけで考えた方がよいです。

理由は、SMS は利便性は高い一方で、より強い方式と比べると安心感が劣るからです。

現実的には、次の順で考えるのが分かりやすいです。

  1. パスキー
  2. 認証アプリ
  3. SMS

サービスが対応しているなら、まずはパスキーを検討したいです。


パスキーが強い理由

パスキーのよいところは、パスワードをそのまま入力しないことです。

使う側としては、

  • 指紋
  • 顔認証
  • 端末のPIN
  • 画面ロック

などでサインインできることが多く、操作も比較的わかりやすいです。

そして重要なのは、フィッシングに強いことです。

「偽サイトにいつものパスワードを入れてしまった」という事故は、パスワード方式では起きえます。
一方で、パスキーはこの種の事故に強い設計です。

つまり、
利便性が高いのに、セキュリティも上げやすい
のがパスキーの大きな利点です。


GitHub では特に MFA / パスキーを後回しにしない

GitHub は、個人開発者でもかなり重要です。

  • ソースコード
  • Issue
  • Pull Request
  • Secrets
  • Actions
  • Deploy 関連

など、仕事や公開物に直結するものが多いからです。

GitHub を触っている人ほど、「とりあえず後でやる」は危険です。

特に、

  • 公開リポジトリを運用している
  • Actions を使っている
  • クラウド連携がある
  • 仕事のコードも置いている

という場合は、優先度はかなり高いです。


Slack も「チャットだから後回し」で済まない

Slack は「ただの連絡手段」と見られがちですが、実際にはかなり情報量が多いです。

  • 内部リンク
  • ファイル
  • 障害時のやり取り
  • 顧客との連携情報
  • ワークスペースの空気感
  • 誰が何を担当しているか

こうしたものが見えること自体がリスクです。

さらに、乗っ取られた後に

  • 怪しいURLを投げる
  • 本人を装ってDMする
  • 他メンバーに認証を促す

といった二次被害も起こりえます。

そのため、Slack も MFA 必須で考えるべきです。


仕事アカウントは「自分だけの問題」で終わらない

仕事用アカウントは、個人アカウントとは重みが違います。

自分が困るだけでなく、

  • 会社
  • 顧客
  • 取引先
  • チームメンバー

へ影響が広がる可能性があります。

つまり、
MFA やパスキーを使うことは、自分のためだけでなく、周囲への最低限の配慮でもある
と言えます。


MFA を入れるときに一緒にやるべきこと

MFA を入れて終わり、ではありません。
復旧できないと逆に詰むことがあります。

1. バックアップコードを安全に保管する

MFA を有効にしたら、バックアップコードやリカバリー手段を必ず確認します。
スクショして放置ではなく、保管場所を決めた方がよいです。

2. 認証端末を失ったときの手順を確認する

スマホ故障・機種変更・紛失は普通に起こります。
そのとき、どう復旧するかを先に把握しておくべきです。

3. 仕事用と私用で認証基盤を分けすぎない

これは少しバランスが必要ですが、何でも分散しすぎると、今度は自分が管理できなくなります。
管理できる単位で整理することが大事です。


現実的なおすすめ運用

個人開発や小規模運用なら、まずは次の形が現実的です。

  • GitHub に MFA またはパスキー
  • Slack に MFA
  • Google / Microsoft の仕事アカウントに MFA またはパスキー
  • パスワードは使い回さない
  • 復旧コードを控える

そして、パスキーが使えるところは徐々に移行する、で十分です。

いきなり全部を最強構成にしなくてもよいですが、
パスワード単体のまま放置する のは避けたいです。


まとめ

GitHub・Slack・仕事アカウントは、
「破られたら面倒」ではなく、「破られたときの影響が大きい」アカウント です。

だからこそ、

  • MFA は必須
  • 可能ならパスキーを優先
  • 復旧方法もセットで整備
  • GitHub / Slack / メール系は最優先

という考え方が大事です。

セキュリティ対策というと難しく見えますが、まずは
仕事で使う重要アカウントを、パスワードだけにしない
ところから始めるだけでも大きく違います。

「あとでやる」になりやすい設定ですが、GitHub・Slack・仕事アカウントについては、早めに済ませておいた方が安心です。


余談:MFA やパスキーでも防げないケースがある

ここまで、GitHub・Slack・仕事アカウントには MFA やパスキーが重要、という話を書いてきました。
これは今でもその通りです。

ただし、1点だけ強く意識しておきたいのは、MFA やパスキーを設定していても防ぎきれない攻撃があるということです。

たとえば近年は、開発者やメンテナー個人に対して、かなり作り込まれたソーシャルエンジニアリングが行われるケースがあります。

  • 実在企業や有名人物になりすまして接触する
  • LinkedIn や Slack などを使って関係を作る
  • オンラインMTGへ誘導する
  • 「会議で必要なファイル」「設定用ファイル」「トラブル回避用ファイル」などと言って不正ファイルを渡す
  • それを「問題ないファイル」と認識して実行してしまい、端末ごと侵害される

この場合、認証方式そのものが強くても、端末側でマルウェアを動かしてしまえば意味が薄れることがあります。

つまり、MFA やパスキーは非常に重要ですが、
「認証が強ければ全部防げる」わけではない
ということです。

特に、GitHub や npm、クラウド、チャット基盤などに関わる開発者は、技術そのものだけでなく、人をだます攻撃にも注意が必要です。

そのため、実務上は次の点も意識したいです。

  • 突然のDMや勧誘、採用連絡、コラボ依頼をすぐ信じない
  • オンラインMTG中に渡されたファイルを安易に開かない
  • 「このファイルを入れれば直る」「このSDKを今入れてほしい」と言われても一度止まる
  • 仕事用端末・開発端末では、渡された実行ファイルやスクリプトを特に慎重に扱う
  • MFA / パスキーに加えて、端末を侵害させない運用も考える

要するに、
認証の強化端末上でだまされないこと は、別の防御レイヤーです。

GitHub・Slack・仕事アカウントを守るなら、MFA やパスキーは必須です。
ただ、それに加えて、「うまく信じ込ませて実行させる攻撃」 があることも知っておいた方が安全です。


関連リンク

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?