GitHub・AWS管理画面利用者のためのVPN活用術｜認証情報・専用IP・通信保護

GitHub・AWS管理画面の安全運用は「パスワード管理 × IP制限 × 通信暗号化」の3層で守ります。

開発者・インフラ担当・フリーランスエンジニアにとって、GitHubリポジトリへのアクセスやAWS管理コンソールへのログインは日常業務の中心です。しかし「認証情報の使い回し」「リポジトリへのシークレット混入」「公共Wi-FiからのAWS Console操作」といった習慣の積み重ねが、深刻なセキュリティインシデントにつながるケースが後を絶ちません。

本記事では、開発・インフラ管理画面のIP制限・認証情報管理に特化した実践的な対策を、NordPass Business（認証情報管理）とNordVPN専用IP（IP制限・通信保護）の組み合わせを軸に解説します。

※ 本記事でNordVPN個人プランに言及する箇所は、個人事業主・フリーランスエンジニアが自身の端末・通信環境を守る個人用途を想定しています。チームや組織全体の管理・監査が必要な場合は、法人向けサービスの検討をあわせておすすめします。

1. なぜGitHub・AWS管理画面が標的になりやすいのか

GitHubとAWS管理コンソールは、攻撃者にとって非常に魅力的なターゲットです。理由は明確で、これらのサービスへのアクセス権を1つ奪うだけで、ソースコード全体・インフラ設定・クラウドリソース・顧客データへの経路が開くからです。

「高権限 × 広範なアクセス」が攻撃の動機

GitHubのリポジトリには、本番環境のAPIキー・データベース接続文字列・SSH秘密鍵が誤ってコミットされているケースが珍しくありません。GitHub公式のSecret scanning機能が検出する漏洩パターンは、2024年時点で1,300種類以上に達しています。

AWSのIAM（Identity and Access Management）のルートアカウントや、過度な権限を持つIAMユーザーが漏洩した場合、攻撃者は仮想マシンの大量起動・データの外部転送・身代金目的のS3バケット操作を数分以内に実行できます。

開発者を狙うインシデントの実態（公式発表ベース）

GitHub Security Advisoryおよび主要メディアの報告から確認できる代表的な被害パターンを示します。

• シークレットのパブリックリポジトリ混入：GitHub公式ブログ（2024年）によると、毎日数十万件のシークレット（APIキー・トークン・認証情報）がパブリックリポジトリにプッシュされていることが検出されています。公式出典：GitHub Docs – About secret scanning
• OAuth Appの不正利用（2022年4月）：GitHubは2022年4月、悪意ある行為者がHerokuおよびTravis CIのOAuth統合を悪用し、多数のOrganizationのプライベートリポジトリに不正アクセスしたインシデントを公式に報告しました。公式出典：GitHub Security Blog – OAuth User Tokens
• AWS認証情報の自動スキャン：攻撃者はGitHubパブリックリポジトリを自動スキャンし、AWSアクセスキーを数秒以内に発見・悪用するツールを運用しています。AWSとGitHubは協力してリアルタイム検出の仕組みを整備していますが、公開後の数秒間に悪用されるリスクはゼロではありません。

これらのインシデントに共通するのは、「アクセス権そのものの管理」と「通信経路の保護」の両方が不可欠という点です。

2. 認証情報漏洩の3パターン

開発者の認証情報が漏洩するルートは、大きく3つのパターンに分類できます。対策を立てる前に、どのルートが自分のワークスタイルに当てはまるかを確認してください。

パターン1：リポジトリへのシークレット混入（Gitへの誤コミット）

最も発生頻度が高いパターンです。.envファイル・設定ファイル・Jupyter NotebookにAPIキーやデータベースパスワードをハードコードしたままgit pushしてしまうケースです。

パブリックリポジトリへの誤プッシュは即座にリスクになりますが、プライベートリポジトリでも組織内の別メンバーや連携サービスが意図せず参照できる状態になりえます。git-secretsやGitleaksなどの静的解析ツールをpre-commitフックに組み込むことが、コードレビュー以前の第一防衛線です。

パターン2：フィッシングによる認証情報の詐取

GitHubやAWSの公式ページに酷似したフィッシングサイトに誘導し、ログイン情報を入力させる手口です。2FAを設定していても、フィッシング経由でOTPを中継する「リアルタイムフィッシング」攻撃が確認されています。TOTP（時刻ベースワンタイムパスワード）よりも、ハードウェアセキュリティキー（YubiKey等）やパスキーがこの攻撃に対して有効です。

パターン3：端末マルウェアによる情報窃取

情報窃取型マルウェア（Infostealer）が端末に侵入した場合、ブラウザに保存されたパスワード・SSH鍵・環境変数・セッションクッキーが自動的に収集されます。NordVPN Threat Protectionのような通信フィルタリング機能は、既知のマルウェア配布ドメインへのアクセスを遮断し、感染リスクを低減します。ただし、端末に侵入済みのマルウェアにはVPN単独では対処できないため、エンドポイントセキュリティ（EDR/アンチウイルス）との併用が必要です。

3. レイヤー1：認証情報管理（NordPass BusinessでGitHub・AWS Console認証を統合）

「パスワードを使い回さない」「強力なランダムパスワードを使う」は、セキュリティの基本原則ですが、GitHubトークン・AWSアクセスキー・SSHパスフレーズ・各SaaSのAPIキーを手動で管理するのは現実的ではありません。NordPass Businessは、開発チームが日常的に扱う多種多様な認証情報を安全に管理・共有するために設計されたパスワード管理ツールです。

NordPass Businessがエンジニアチームに選ばれる理由

GitHub・AWSへの適用イメージ

具体的な活用として、以下の認証情報をNordPass Businessで管理することが考えられます。

• GitHubアカウントのパスワード（Personal Access Token発行前の初期ログイン）
• AWS IAMユーザーのコンソールログインパスワード
• Staging環境・CI/CD（GitHub Actions等）のサービスアカウント認証情報
• 各種SaaS（Datadog・Sentry・Cloudflare等）のAPIキー・シークレット
• VPN接続用のパスフレーズ

なお、GitHub ActionsのシークレットはGitHub側のSecrets管理機能と組み合わせて使うのが基本です。NordPass BusinessはCI/CDパイプライン内の秘密管理を代替するものではなく、人間が操作する管理コンソール・開発ツールの認証情報を守る領域を補完します。

4. レイヤー2：アクセス制限（VPN専用IPでGitHub Enterprise・AWS IAMのIP制限を活用）

認証情報の管理と並んで有効なのが、管理コンソールへのアクセス元IPアドレスを特定のIPに制限する設計です。認証情報が漏洩した場合でも、許可されたIPからのアクセスでなければログインを拒否できます。

GitHub EnterpriseのIP allowlist機能

GitHub Enterprise Cloud（有料プラン）では、OrganizationまたはEnterpriseレベルでIP allowlistを設定できます。許可されたIPアドレス範囲以外からのアクセスをブロックする機能です。

• 設定場所：Organization Settings → Security → IP Allow List
• 設定方法：許可するIPアドレスまたはCIDR範囲を追加する
• 対象：GitHubのWeb UI・GitHub API・GitHubへのgit push/pull

公式ドキュメント：GitHub Docs – Managing allowed IP addresses

重要：VPN専用IPを使ったIP allowlist運用について
NordVPNには「専用IP（Dedicated IP）」オプションがあり、月額5ドル前後で特定の固定IPアドレスを割り当てることが可能です。この専用IPをGitHub EnterpriseのIP allowlistに登録することで、チームメンバーがどこからアクセスしてもVPN接続経由であれば許可されるIP制限の運用が設定により実現できます。実際の動作はGitHub側の設定内容・プラン・ネットワーク構成に依存するため、事前に検証環境での動作確認を強く推奨します。

AWS IAM・AWS Organizations によるIP制限

AWSではIAMポリシーの条件要素（Condition）を使って、特定のIPアドレスからのみAPIコール・Console操作を許可する設定が可能です。

AWS IAMドキュメントに示されているIP制限のポリシー例（公式ドキュメントより）：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "NotIpAddress": {
          "aws:SourceIp": [
            "YOUR.DEDICATED.IP.HERE/32"
          ]
        }
      }
    }
  ]
}

このポリシーを適用すると、YOUR.DEDICATED.IP.HERE以外のIPからのすべてのAWS APIコールを拒否します。実際の運用では、複数の許可IPを列挙する・ルートアカウントには適用しない・緊急アクセス用のBreakGlassアカウントを別途用意するなど、運用設計が必要です。

公式ドキュメント：AWS IAM – Deny access based on source IP

VPN専用IPとAWS IAMポリシーの組み合わせ
NordVPNの専用IPをIAMポリシーのaws:SourceIpに登録することで、VPN接続なしのAWSアクセスを拒否する運用が設定により構成できます。リモートワーク環境・外出先からの作業時でも、VPN経由であれば一貫したIP制限が機能します。

5. レイヤー3：通信暗号化（公共Wi-Fi利用時のVPN）

カフェ・コワーキングスペース・出張先ホテルなど公共ネットワーク環境からGitHub・AWS管理コンソールにアクセスする場合、VPNによる通信の暗号化が追加の保護層として機能します。

公共Wi-Fiが危険な理由

IPA（独立行政法人情報処理推進機構）の公衆無線LANに係る脅威整理（継続公開）では、以下のリスクが示されています。

• 通信盗聴：暗号化が不十分なWi-Fiでは、同一ネットワーク上の第三者が通信パケットを傍受できる可能性がある
• なりすましアクセスポイント（Evil Twin）：正規のWi-Fiに見せかけた偽APに接続させ、通信を中継する攻撃
• セッションハイジャック：Webサービスのセッションクッキーを盗み取り、ログイン状態を乗っ取る攻撃

GitHubもAWS ConsoleもHTTPS（TLS）で暗号化されていますが、公共ネットワーク上での追加の保護としてVPNを使うことで、通信経路全体をVPNトンネルで包む設計が可能です。

VPN接続の順序と注意点

効果的な保護のために、接続順序を守ることが重要です。

1. 公共Wi-Fiに接続する
2. VPNアプリを起動し、VPN接続を確立する
3. GitHub・AWS管理コンソールにアクセスする

VPN接続前にサービスへのアクセスを開始してしまうと、VPN経由でない通信がすでに発生している点に注意が必要です。NordVPNのKill Switch機能を有効にすると、VPN接続が切断された場合に自動でインターネット通信を遮断し、VPN経由でない素のトラフィックが漏れることを防ぎます。

NordVPN Threat Protectionでマルウェア配布サイトをブロック

NordVPN Threat Protection（旧CyberSec）は、既知のマルウェア配布ドメイン・フィッシングサイトへのアクセスをDNSレベルでブロックします。GitHubやAWSになりすましたフィッシングページへの誘導リスクを低減する効果があります。

6. GitHub Personal Access Token / AWS IAMアクセスキーの安全運用

認証情報の中でも、特に管理が難しいのがGitHubのPersonal Access Token（PAT）とAWS IAMのアクセスキーです。パスワードとは異なり、これらは「プログラムからAPIを呼び出すためのトークン」であり、漏洩した場合の影響範囲が大きくなりがちです。

GitHub Personal Access Tokenのベストプラクティス

• Fine-grained PATを使う：Classic PATよりも権限を細かく絞れるFine-grained Personal Access Tokenを優先的に使用する（GitHub公式推奨）
• 最小権限の原則：必要なリポジトリ・必要な操作（read / write）だけに権限を絞る
• 有効期限を設定する：有効期限なしのPATは避け、30〜90日の有効期限を設定する
• 用途別にトークンを分ける：CI/CD用・個人開発用・スクリプト用でトークンを分離する
• 漏洩したら即座にRotate：GitHub管理画面（Settings → Developer Settings → Personal Access Tokens）から即時削除・再発行する

AWS IAMアクセスキーのベストプラクティス

AWS公式の「IAM Best Practices」（AWS IAM Best Practices）では、以下の方針が推奨されています。

• ルートアカウントのアクセスキーを作成しない：ルートアカウントにはアクセスキーを発行せず、日常業務は個別のIAMユーザーまたはIAMロールで行う
• 最小権限ポリシー：アクセスキーに付与するIAMポリシーは、必要な操作のみに絞る
• 90日ごとのRotation：アクセスキーを定期的に再発行し、古いキーを無効化する
• AWS Secrets Managerを活用：アプリケーションからAWSサービスを呼び出す場合は、ハードコードを避けてAWS Secrets Managerまたは環境変数経由で渡す
• AWS CloudTrailで監査ログを有効化：どのIAMエンティティがいつ何のAPIコールをしたか記録し、不審なアクセスを早期検出する

NordPass Businessは、AWS IAMのコンソールログインパスワードや、開発者が管理するSaaSサービスの認証情報（AWS関連の設定を行うサードパーティツールのAPIキー等）を安全に保管・共有する用途に活用できます。AWS Secrets Manager自体の管理認証情報もNordPass Businessで管理することで、管理認証情報の体系を整理できます。

7. SSH鍵管理とパスワード管理ツールの組み合わせ

GitHubへのアクセス手段として、パスワード認証よりもSSH鍵認証が推奨されています。SSH鍵はパスワードより強力な認証を実現しますが、秘密鍵のパスフレーズ管理と鍵ファイルのバックアップ・失効管理が新たな課題になります。

SSH鍵の基本的なセキュリティ設計

• パスフレーズを必ず設定する：ssh-keygenで鍵を生成する際、空のパスフレーズは避ける。端末が盗まれた場合でも、パスフレーズなしの秘密鍵はすぐに悪用される
• デバイス別に鍵を分ける：PC・MacBook・自宅サーバーなど端末ごとに異なるSSH鍵を使用し、1台の端末が侵害されても他の端末の鍵が有効なままにならないようにする
• 定期的な鍵のRotation：年1回程度、古い鍵を廃止して新しい鍵を発行する
• GitHub側で登録鍵を定期確認：GitHubのSettings → SSH and GPG keysから登録鍵の一覧を確認し、使用していない鍵を削除する

NordPass BusinessでSSH鍵パスフレーズを管理する

SSH秘密鍵ファイル（~/.ssh/id_ed25519等）そのものをNordPassに保存するのではなく、秘密鍵のパスフレーズをNordPass Businessに保存することで、強力でランダムなパスフレーズを使いつつ記憶の負担を軽減できます。

また、NordPass BusinessのSecure Notesとして、SSH公開鍵のフィンガープリント一覧・登録先サービス・失効手順を記録しておくことで、インシデント発生時の対応を素早く進められます。

ハードウェアセキュリティキー（YubiKey）との併用

最高水準の認証強度を求める場合、YubiKey等のハードウェアセキュリティキーとパスワードマネージャーの組み合わせが有効です。

• GitHubはWebAuthn/FIDO2によるYubiKey認証をサポートしており、フィッシング耐性の高い認証が実現できます
• YubiKeyをSSH認証に使う構成（ecdsa-sk鍵型）も可能です
• YubiKeyのPIN・バックアップコード・管理先はNordPass Businessで管理することで、デバイス紛失時の対応手順を体系化できます

8. 2段階認証（GitHub: TOTP / WebAuthn、AWS: MFA）の必須化

認証情報管理・IP制限・通信保護の3層に加えて、2段階認証（2FA / MFA）の有効化はすべてのGitHub・AWSアカウントで行うべき基本対策です。

GitHubの2FA設定

GitHub公式は2023年以降、すべての開発者アカウントに対して2FAの有効化を必須化する方向で進めています（公式発表：GitHub Blog – Raising the bar for software security: GitHub 2FA）。

GitHubが対応する2FA方式の強度比較：

AWS MFAの設定

AWSではIAMユーザー・ルートアカウントそれぞれにMFAを設定できます。AWS IAM Best Practicesでは、ルートアカウントへのMFA設定を最優先として推奨しています。

• AWS Console → Security credentials → Multi-factor authentication でTOTPまたはハードウェアMFAを設定
• IAMポリシーで「MFA未認証の場合はAPIコールを拒否する」条件を設定することで、MFA通過なしのアクセスを組織的にブロックできる

AWS Organizations管理下の環境では、Service Control Policy（SCP）を使ってMFA必須ポリシーを全アカウントに強制適用することが可能です（公式ドキュメント：AWS Organizations – SCPs）。

9. インシデント発生時の対処手順

認証情報漏洩・不正アクセスが疑われる場合は、以下の手順で速やかに対処します。発見から無効化までの時間が短いほど、被害範囲を限定できます。

1. Step 1：漏洩したトークン・キーを即時無効化する

   GitHubのPATが漏洩した疑いがある場合：Settings → Developer Settings → Personal Access Tokens で該当トークンを即時削除します。AWSアクセスキーが漏洩した場合：IAM管理コンソールで該当キーを「Inactive」に設定し、数分後に削除します（即削除ではなくInactive設定から始めることで、依存アプリへの影響を確認しながら進められます）。

2. Step 2：GitHubリポジトリのコミット履歴を確認・クリーニングする

   シークレットがコミット履歴に含まれていた場合、git pushしただけでは公開状態が続きます。git filter-repoやBFG Repo Cleanerを使ってコミット履歴からシークレットを削除し、強制プッシュ（git push --force）する必要があります。ただし、GitHub側のキャッシュ・フォーク・クローンに残っている可能性があるため、トークンを無効化することが最優先です。

3. Step 3：AWSのCloudTrailログで不審な操作を確認する

   AWSコンソール → CloudTrail → Event Historyで、漏洩したアクセスキーを使ったAPIコールの履歴を確認します。不審なEC2起動・S3アクセス・IAMユーザー追加などが検出された場合は、追加の対応が必要です。

4. Step 4：GitHubのSecurity Logを確認する

   GitHub Organization → Settings → Audit log で、不審なログイン・リポジトリアクセス・設定変更の履歴を確認します。見覚えのないIPからのアクセスがある場合は、すべてのセッションを強制終了（Settings → Sessions → Sign out of all sessions）します。

5. Step 5：パスワード・2FA設定を全面見直しする

   漏洩した認証情報のパスワードを変更し、再発防止のため2FAが有効になっていない関連アカウントに2FAを設定します。NordPass Businessの漏洩スキャン機能で、同一パスワードを使い回している他のサービスを確認し、一括更新します。

6. Step 6：NordPass Businessで認証情報体系を再構築する

   インシデント収束後、NordPass Businessを使って認証情報の棚卸しを行います。弱いパスワード・有効期限切れトークン・使い回しパスワードを一覧で確認し、体系的に更新します。再発防止のため、GitHub PAT・AWSアクセスキーの有効期限ポリシーをチームで合意します。

10. NordPass Business + NordVPN専用IPの組み合わせ事例

ここまで解説した3つのレイヤーを、NordPass BusinessとNordVPN専用IPの組み合わせで実装する全体像を整理します。

フリーランスエンジニア（個人）の典型的な活用パターン

NordLockerによる開発アセットの保護

NordLockerは暗号化されたクラウドストレージです。SSHの秘密鍵バックアップ・.envファイルのローカル保管用途には活用できますが、本番環境やCI/CDパイプラインの秘密情報管理にはAWS Secrets Manager・GitHub Secretsが適切です。個人の開発環境における機密ファイルのバックアップ・暗号化保管という補完的な役割で検討してください。

#6 ChatGPT記事との使い分け

本記事（#5）は開発・インフラ管理画面のIP制限・認証情報管理に特化しています。AIで設定値を生成する場合・ChatGPTにコードを書かせる際の情報漏洩対策については、ChatGPT業務利用時の情報漏洩対策とVPN（#6）をあわせてご参照ください。

11. まとめ

GitHub・AWS管理画面を安全に運用するための3層防御を整理します。

• レイヤー1（認証情報管理）：NordPass Businessで全認証情報を一元管理。強力なランダムパスワード・有効期限付きトークンを体系的に運用し、退職時のアクセス剥奪を自動化する
• レイヤー2（IP制限）：NordVPN専用IPをGitHub EnterpriseのIP allowlistやAWS IAMポリシーに登録し、設定により特定IPからのみアクセスを許可する構成を実現する
• レイヤー3（通信保護）：公共Wi-Fiからのアクセス時はVPNで通信を暗号化。Threat Protectionで既知の悪意あるドメインをブロック。Kill Switchで素通しを防止する

この3層は、単独での実装よりも組み合わせることで相互に補完します。認証情報が漏洩しても IP制限があれば悪用を防ぎ、IP制限を突破されても2FAが最後の壁になります。どの1層も「これだけで万全」という対策はなく、多層防御の設計が現実的なリスク低減につながります。

IPA（独立行政法人情報処理推進機構）の「テクニカルウォッチ／調査レポート一覧」（IPA公式）に整理された開発環境セキュリティ関連レポートでは、開発環境における認証管理・アクセス制御・通信保護の重要性が示されており、本記事で解説した対策はこの観点とも整合しています。

12. よくある質問（FAQ）

基本FAQ

Q1. GitHubのアカウント乗っ取りはどう起きますか？

GitHubアカウントの乗っ取りは主に3つのルートで発生します。(1)弱いパスワードや使い回しパスワードへのブルートフォース・クレデンシャルスタッフィング攻撃、(2)GitHubを装ったフィッシングサイトへの誘導でログイン情報を詐取する手口、(3)端末に侵入した情報窃取型マルウェアによるブラウザ保存パスワードやセッションクッキーの盗取、です。2FAとパスワードマネージャーの組み合わせが基本対策になります。

詳細は「認証情報漏洩の3パターン」セクションをご参照ください。

Q2. AWS ConsoleのログインにVPNは必要ですか？

必須ではありませんが、公共Wi-Fiからのアクセス時の通信保護として有効です。VPNによるIP制限（IAMポリシーのaws:SourceIp条件）を組み合わせる場合は、専用IP付きVPNが必要になります。また、フィッシングサイトやマルウェア配布ドメインへのアクセスを防ぐThreat Protection機能も、AWSへの不正アクセス経路を減らす効果があります。

Q3. Personal Access Tokenを複数人で共有しても大丈夫ですか？

推奨されません。PATはトークンを所有する個人の権限で動作するため、共有すると誰が何の操作をしたか追跡できなくなります。チームで使う場合は、GitHub Apps（特定の権限セットを持つアプリとして登録）やFine-grained PATをユーザーごとに発行することを推奨します。NordPass Businessのチーム共有Vaultは、チームが共有すべき認証情報（サービスアカウントのパスワード等）を安全に管理する用途に適しています。

応用FAQ

Q4. 専用IPでAWS IAMポリシーを絞るとリスクはどう減りますか？

IAMポリシーにNotIpAddressの条件でDeny設定を加えると、漏洩したAWSアクセスキーを攻撃者が別のIPから使おうとしてもAPIコールが拒否されます。認証情報の漏洩という最悪の事態が発生しても、不正なIPからの操作を設定によりブロックできる点が主なリスク低減効果です。ただし、VPN接続が切断された場合はアクセスできなくなるため、Kill SwitchとIP制限の組み合わせについて事前に運用設計が必要です。

Q5. NordPass BusinessとAWS Secrets Managerは併用すべきですか？

役割が異なるため、併用が合理的です。AWS Secrets Managerはアプリケーション・CI/CDパイプラインがプログラムからシークレットを取得するためのものです。NordPass Businessは人間が操作する管理コンソール・開発ツールの認証情報を管理するためのものです。AWS Console自体のIAMログインパスワードはNordPass Businessで、本番環境のアプリケーションシークレットはAWS Secrets Managerで管理するという役割分担が整理しやすい設計です。

Q6. チームでGitHub Enterprise + VPNを運用する手順を教えてください。

基本的な導入手順は(1)NordPass Businessをチームに展開してGitHub・AWSの認証情報を移行する、(2)NordVPN専用IPを取得して全メンバーに配布・VPNプロファイルを設定する、(3)GitHub EnterpriseのIP allowlistに専用IPを登録して動作確認する、(4)AWS IAMポリシーにIP制限を段階的に適用してエラーがないか確認する、(5)CloudTrailとGitHub Audit logで定期的に不審なアクセスをモニタリングする、という流れになります。IPリストへの登録はGitHub Enterprise Cloud（GHEC）プランが必要な点に注意してください。

上級FAQ

Q7. NordVPN個人プランの専用IPでGitHub IP制限は実用的ですか？

フリーランスエンジニアや個人規模での利用では実用的な選択肢です。ただし、GitHub EnterpriseのIP allowlistはEnterprise Cloud（GHEC）プランの機能であり、個人の無料・Proアカウントには提供されていません。また、実際の動作はGitHub側の設定・ネットワーク構成に依存するため、本番適用前に必ずテスト環境で動作を確認してください。「専用IPを登録すれば確実にIP制限が機能する」ではなく、「設定により実現できる可能性がある」という理解が正確です。

Q8. YubiKeyとパスワードマネージャーは併用すべきですか？

高いセキュリティ水準が必要な環境では有効な組み合わせです。YubiKey（WebAuthn/FIDO2）はフィッシング耐性の高い認証を実現し、パスワードマネージャーは強力なパスワードの管理と2FAバックアップコードの保管を担います。実際の運用では、NordPass Businessでパスワードとバックアップコードを保管しつつ、WebAuthn対応のYubiKeyをメインの2FA手段として使う構成が一般的です。YubiKeyのPINや登録情報もNordPass Businessのセキュアノートに記録しておくと、紛失時の対応がスムーズです。

Q9. git-secrets・Banditとの組み合わせはどう考えればよいですか？

git-secrets（シークレット混入防止のpre-commitフック）やBandit（Pythonコードの静的セキュリティ解析）は、本記事で解説した対策の「コード層での防御」を担います。NordPass Business・NordVPN専用IPは「人間の認証・通信経路の防御」を担います。両者は補完関係にあり、どちらが優先ということはありません。理想的には、git-secretsのpre-commitフックでシークレット混入を防ぎ、GitHub Advanced SecurityのSecret scanningで検出し、NordPass Businessで認証情報を管理し、NordVPNで通信を保護するという多層防御の全層を実装することが、最も安全な開発環境の設計です。

この記事の監修者

江田 健二
RAUL株式会社 代表取締役

慶應義塾大学卒業後、アクセンチュアにてエネルギー・IT分野のコンサルに従事。2005年にRAUL株式会社を設立し、これまでITコンサルタントとして、企業のシステム開発支援からWebマーケティング戦略まで幅広い領域を支援してきた実績を持つ。
ITやデジタルテクノロジーおよびエネルギー業界・電力ビジネスに精通しており、デジタルと社会インフラの接点を捉えた情報発信に力を入れており、日常生活の中で役立つ視点からわかりやすく伝えることを大切にしている。
光回線、VPN、PC、格安SIM、電力系のメディアを複数運営。
Yahoo!ニュース公式コメンテーターやテレビ・ウェブメディアでも幅広く発信中。

2026年5月22日 Netflixでジブリは見れる？日本配信状況・見れる国・VPNで見る手順【2026年5月】

2026年5月22日 ExpressVPNの評判・口コミ【2026年最新】実測＋23名調査｜速度・中国・料金を正直レビュー

2026年5月22日 NordVPNの評判・口コミ【2026年最新】40人調査＋実測｜速度・中国・料金のメリット・デメリット

2026年5月22日 かべネコVPNの評判・口コミ【2026年最新】中国接続・セキュリティ・料金を徹底調査

2026年5月22日 Surfsharkの評判は？【実測4社比較】口コミ・料金・デメリットを解説

2026年5月22日 VPN Gate（筑波大学VPN）の使い方｜危険性と安全な接続手順【2026年最新】

2026年5月22日 Netflix韓国版を日本から見れる？【2026年最新】原因・VPNの注意点を解説

人気VPNサービスを比較

名称	ExpressVPN	NordVPN	かべネコVPN	セカイVPN	スイカVPN	ミレンVPN	良之助VPN	SurfsharkVPN	CyberGhostVPN
おすすめ順位	1位	2位	3位	4位	5位	6位	7位	8位	9位
使いやすさ	最高	最高	最高	良い	最高	良い	良い	良い	良い
ユーザー数	多い	多い	多い	多い	普通	普通	多い	普通	普通
通信速度	高速	高速	高速	やや遅い	速い	速い	速い	高速	高速
動画配信対応	多い	豊富	少ない	少ない	豊富	多い	多い	多い	多い
中国対応	不安定（時期・設定次第）	公式保証なし（不安定）	比較的強い	不安定（方式次第）	比較的強い	不安定（状況次第）	比較的強い	公式保証なし（不安定）	公式保証なし（不安定）
同時接続数	最大14台（Basic/Advanced/Proで10/12/14）	最大10台	4台	3台	最大50台（※方式・サーバーで制限あり）	無制限（同時接続制限撤廃）	2台	無制限	7台
スマホ/PC/タブレット	全て対応	全て対応	全て対応	全て対応	全て対応	全て対応	全て対応	全て対応	全て対応
iOS/Android	全て対応	全て対応	全て対応	全て対応	全て対応	全て対応	全て対応	全て対応	全て対応
セキュリティ	安心	安心	安心	安心	安心	安心	安心	安心	安心
サポートの雰囲気	丁寧	普通	丁寧	丁寧	普通	普通	普通	普通	普通
日本語サポート	チャットのみ	チャットのみ	全て	全て	全て	全て	全て	日本語ページあり	日本語ページあり
料金（1ヶ月）	約$12.95〜19.99（約2,000円前後）	約$11〜14（約1,700〜2,000円前後）	880円（税込）	1,100円（税込）	約950〜1,045円（税抜）	1,738円（税込）	約1,000円前後	約$15.45（約2,300円前後）	約$12〜13（約1,800〜2,000円前後）
料金（12ヶ月）	約$3.99〜7.19/月（約1,000円前後）	約$4〜6/月（約600〜900円前後）	480円/月（年間5,760円）	1,100円（税込）	割引あり（約825円/月）	約594円/月	約1,100円/月	約$2.99/月（約450〜500円）	—（12ヶ月プランなし）
料金（2年/24ヶ月〜）	約$2.79〜5.99/月（約500〜700円前後）	約$3〜4/月（約400〜600円前後）	—（2年プランなし）	1,100円（税込）	約878円/月	約396円/月	—（2年プランなし）	約$1.99/月（約300〜400円）	約$2.19/月（約300〜400円）
キャンペーン情報	最大78%OFF（時期で変動）	最大70%OFF（時期で変動）	クーポン/割引がある場合あり（公式で確認）	キャンペーンは随時変動（公式で確認）	最大5.5ヶ月分割引（時期で変動）	最大75%OFF（時期で変動）	キャンペーン/特典は公式で確認	最大86%OFF＋追加3ヶ月（時期で変動）	84%OFF＋4ヶ月無料（2年プラン、時期で変動）
無料体験	30日間返金保証（iOS/Androidは3日無料あり）	30日間返金保証	14日間（※最大21日表記あり／時期で変動）	2ヶ月	30日間無料キャンセル	30日間返金保証	1週間	30日間返金保証	45日間返金保証（1ヶ月は14日）
公式サイト	公式サイト	公式サイト	公式サイト	公式サイト	公式サイト	公式サイト	公式サイト	公式サイト	公式サイト