{"meta":{"title":"シークレットを安全に格納する","intro":"ソフトウェア開発でのシークレットと、それを安全に管理する方法について説明します。","product":"概要","breadcrumbs":[{"href":"/ja/get-started","title":"概要"},{"href":"/ja/get-started/learning-to-code","title":"コードの学習"},{"href":"/ja/get-started/learning-to-code/storing-your-secrets-safely","title":"シークレットを安全に格納する"}],"documentType":"article"},"body":"# シークレットを安全に格納する\n\nソフトウェア開発でのシークレットと、それを安全に管理する方法について説明します。\n\n## シークレットとは\n\nソフトウェア開発でのシークレットは、システム、サービス、データ、API へのアクセスを認証または認可するために使われる機密情報です。 以下に例を示します。\n\n* **API キー**と**アクセス トークン**: GitHub の REST API などの外部サービスを操作するために使用できます。 アクセス トークンを使うと、GitHub Actions などのサービスで認証が必要なタスクを実行することもできます。これについては後で説明します。\n* **データベース資格情報**: ローカルと外部のデータベースとストレージへのアクセスを許可します。\n* **秘密キー**: SSH や PGP などの秘密キーは、他のサーバーへのアクセスやデータの暗号化に使用できます。\n\nシークレットは非常に多くのアクセスを提供し、それには重要なシステムも含まれるため、**シークレットをセキュリティで保護する**ことが非常に重要であることがわかります。\n\n### シークレットが露出されると発生する可能性があること\n\n* 攻撃者は、シークレットによってアクセスが許可されるすべてのものに**認可なしでアクセス**できます。\n* ハッカーは、機密ユーザー データなどの**データを盗む**ことができます。 これにより、プライバシーと法律に関する予期しない事態が発生し、お客様とそのアプリケーションに対する信頼が損なわれる可能性があります。\n* 露出されたシークレットによって、ハッカーがクラウド プロバイダー アカウントで未認可のワークロードを実行した場合、**お客様にコストが発生する**可能性があります。\n* ハッカーは、露出されたシークレットを使ってサーバーを削除、変更、中断することができ、**ダウンタイムやデータ損失**を引き起こす可能性があります。\n\nシークレットによってお客様が利用できるようになるすべてのアクセスと能力、そしてハッカーがそれを使ってできることを考えてみてください。 たとえば、personal access token アカウントの GitHub が露出されると、ハッカーがあなたになりすまして GitHub に投稿したり、変更を加えることができる可能性があります。\n\n## シークレットの管理に関するベスト プラクティス\n\nこのような問題を避けるには、ベスト プラクティスに従って漏洩を防ぎ、シークレットが露出された場合の損害を制限します。\n\n### **最小限の特権の原則 (PoLP)** に従う\n\n可能な限り、シークレットの機能とアクセスを必要な範囲に限って制限します。 次に例を示します。\n\n* シークレットがデータの読み取りにのみ使われ、データを変更しない場合は、**読み取り専用**にします。\n* お使いの API でシークレットを特定のスコープまたはアクセス許可のみに制限できる場合は、**必要なもの**のみを選びます。 たとえば、GitHub シークレットを使用して issue のみを作成する必要がある場合、そのシークレットにリポジトリの内容やその他のものへのアクセス権がある理由はありません。\n* シークレットによってそれを所有するユーザー アカウントへのフル アクセス権が攻撃者に与えられる場合は、シークレットの所有権を取得できる**サービス アカウントの作成を検討**します。\n\n### アプリケーションでシークレットを保護する\n\n* **シークレットをハードコーディングしてはなりません**。 常に、**環境変数**またはプラットフォームのシークレット管理ツール (GitHub のリポジトリ シークレットなど) を使います。\n* シークレットを他のユーザーと共有する必要がある場合は、**パスワード マネージャー**などの専用ツールを使います。 メールやインスタント メッセージを使ってシークレットを送信してはなりません。\n* 可能であれば、**有効期限**を設定し、定期的に**シークレットをローテーション**します。これにより、古いシークレットが悪用されるリスクが減ります。\n* アプリケーションでログが生成される場合は、**ログに記録される前にシークレットが削除されている**ことを確認します。 そうしないと、アクティブなシークレットがプレーンテキスト ファイルに保存される可能性があります。\n\n### シークレットが露出された場合の被害を制限する\n\n* たとえ露出されたのが 1 秒間だけであっても、シークレットの侵害を考慮して、**シークレットをすぐに取り消します**。 その後、新しいシークレットを生成し、安全に格納します。\n* 侵害されたシークレットで実行された疑わしいアクティビティを示している可能性がある**アクティビティ ログ**を調べます。\n* シークレットがどのようにして露出されたかを検討し、二度と発生しないようにプロセスを変更します。\n\n## GitHub はシークレットのセキュリティ保護にどのように役立つか\n\nシークレットを安全に保つためにできることは数多くありますが、GitHub にもシークレットの機密の維持に役立つ機能がたくさんあります。 誰でも間違いを犯すので、誤って露出されたシークレットをキャッチする機能が用意されています。\n\n* **プッシュ保護**は、GitHub 上のリポジトリへのシークレットのプッシュをブロックします (後で説明します)。\n* **シークレット スキャン**は、リポジトリをスキャンし、シークレットが検出されたらアラートを作成します。 一部のシークレットについては、シークレットの自動取り消しなどのアクションを実行できるように、プロバイダーにも通知します。\n\n## シークレットの安全な保管の実践\n\nこの練習では、personal access token を作成し、それを安全に格納して、GitHub Actions で使えるようにします。 作成するアクションは、issue に対応する簡単なワークフローです。\n\n### 1.練習用のリポジトリを作成する\n\n最初に、作業用のリポジトリを作成します。\n`new2code` アカウントには、すぐに作業を始めるのに使用できるテンプレート リポジトリがあります。\n\n1. [新しいリポジトリのページ](https://github.com/new?template_owner=new2code\\&template_name=secret-action)に移動します。 このリンクに従うと、`new2code` アカウントでテンプレートが事前に選択されています。\n2. \\[Owner] で、自分のユーザー アカウントが選ばれていることを確認します。\n3. \\[Repository name] フィールドに「`secret-action`」と入力します。\n4. 説明フィールドの下で **\\[Public]** を選んでリポジトリの可視性を設定します。\n5. **リポジトリの作成**をクリックします。\n\n### 2.ダミー トークンをコミットする\n\n誰もが間違いを犯すものであり、コーディングの過程のどこかで誤ってシークレットをコミットする可能性があります。 この演習では、トリガーされるアラートに慣れ親しみやすくなるように、意図的に**偽のトークン**をコミットします。\n\n1. 先ほど作成したリポジトリに移動します。\n\n2. ファイルの一覧で `.github/workflows` をクリックして、YAML ワークフロー ファイルに移動します。\n\n3. ファイルの一覧で `comment.yml` をクリックして、ワークフロー ファイルを開きます。\n\n4. ワークフロー ファイルを編集するには、右上の をクリックします。\n\n5. 13 行目の `GH_TOKEN: \"\"` で、引用符の間に次のダミー トークンを挿入します。\n\n ```text\n secret_scanning_ab85fc6f8d7638cf1c11da812da308d43_abcde\n ```\n\n 最終的な結果はこのようになります。\n\n ```yaml\n GH_TOKEN: \"secret_scanning_ab85fc6f8d7638cf1c11da812da308d43_abcde\"\n ```\n\n6. 変更をコミットするには、右上の **\\[Commit changes...]** をクリックした後、ダイアログでもう一度 **\\[Commit changes]** をクリックします。\n\n7. プッシュ保護アラートが表示され、\"シークレットスキャンにより、13行目でGitHubシークレットスキャンのシークレットが見つかりました\" というメッセージが表示されます。\n\n ![コミットしようとしたファイルの 13 行目に関するプッシュ保護アラートのスクリーンショット。 \\[Cancel\\] ボタンがオレンジ色の枠線で強調されています。](/assets/images/help/security/push-protection-example.png)\n\n ダミー トークンで試していなかったら、これは一歩間違えばトークンが露出されることを警告するものです。 アラートに対して選択できるオプションを確認します。\n\n8. コミットを停止し、シークレットが露出されないようにするには、**\\[Cancel]** をクリックします。 右上の **\\[Cancel changes]** をクリックし、メッセージが表示されたら保存されていない変更を破棄します。\n\n### 3.実際のトークンを作成する\n\nそれでは、ベスト プラクティスに従ってみましょう。 最初に、ユーザーに代わってアクションを実行できる personal access token を作成します (作成されるコメントはユーザー アカウントから送信されているように見えます)。\n\n> \\[!NOTE] 各構成ステップで最小特権の原則にどのように従っているのかに注意してください。 トークンは、必要な最短の有効期限を持ち、必要なリポジトリにのみアクセスでき、作業に必要な最小限のアクセス許可を持ちます。\n\n1. [新しい personal access token ページ](https://github.com/settings/personal-access-tokens/new)に移動します。\n2. \\[Token name] で新しいトークンの名前を指定します。 \"Action token\" のようなものを使用できます。\n3. \\[Expiration] で \\[7 days] を選びます。\n4. 「リポジトリ アクセス」で **「選択されたリポジトリのみ」** を選びます。\n5. \\[Select repositories] ドロップダウンで、前に作成した演習用リポジトリ**だけ**を選びます。\n6. \\[Permissions] セクションの \\[Repository permissions] の右にある をクリックして、使用可能なすべてのアクセス許可を表示します。\n7. \\[Issues] まで下にスクロールし、右側のドロップダウンで \\[Read and write] を選びます。\n8. ページの下部にある **\\[Generate token]** をクリックします。 メッセージが表示されたら、もう一度 **\\[Generate token]** をクリックして確認します。\n\nこの瞬間から、結果のトークンを安全に取り扱うことが極めて重要です。 この後すぐにトークンを使うので、簡単にクリップボードにコピーしておいてかまいません。\n\n### 4. トークンを安全に格納する\n\nこれで、新しいトークンをリポジトリに安全に格納できるようになりました。\n\n1. 演習を始めるときに作成したリポジトリに移動します。\n2. リポジトリ名の下にある ** \\[Settings]** をクリックします。 \\[設定] タブが表示されない場合は、 **\\[]** ドロップダウン メニューを選び、 **\\[設定]** をクリックします。\n\n ![タブを示すリポジトリ ヘッダーのスクリーンショット。 \\[設定\\] タブが濃いオレンジ色の枠線で強調表示されています。](/assets/images/help/repository/repo-actions-settings.png)\n3. サイドバーの \\[Security] セクションで、** \\[Secrets and variables]** を選んでから、**\\[Actions]** をクリックします。\n4. \\[Repository secrets] で **\\[New repository secret]** をクリックします。\n5. **\\[Name]** フィールドにシークレットの名前を入力します。 この演習では、`MY_TOKEN` を使用します。\n6. **\\[Secret]** フィールドに、前に生成した personal access token を貼り付けます。\n7. **\\[シークレットの追加]** をクリックします。\n\nシークレットが安全に暗号化され、使用する準備が整いました。\n\n### 5.アクションでトークンを参照する\n\nこれで、トークンを使うように YAML ワークフロー ファイルを更新し、動作をテストできます。\n\n1. リポジトリに戻ります。 リポジトリの設定が表示されている場合は、リポジトリ名の下の **\\[ Code]** をクリックできます。\n\n2. ファイルの一覧で `.github/workflows` をクリックして、YAML ワークフロー ファイルに移動します。\n\n3. ファイルの一覧で `comment.yml` をクリックして、ワークフロー ファイルを開きます。\n\n4. ワークフロー ファイルの編集を始めるには、右上の をクリックします。\n\n5. 13 行目の `GH_TOKEN: \"\"` で、空の引用符を `${{ secrets.MY_TOKEN }}` に置き換えます。 これは、前に追加したリポジトリ シークレットを参照しています。\n\n ```yaml\n GH_TOKEN: ${{ secrets.MY_TOKEN }}\n ```\n\n6. 変更をコミットするには、右上の **\\[Commit changes...]** をクリックします。\n\n7. \\[Commit changes] ダイアログで、\\[Commit message] を編集して行っている変更を反映します。 たとえば、「リポジトリの秘密情報を使用するためのワークフローの更新」などと入力します。\n\n8. \\[`main` ブランチに直接コミットする] が選択されていることを確認します。\n\n9. **\\[Commit changes]** をクリックします。\n\n### 6.トークンとワークフローをテストする\n\nこれで設定はすべて終わりです。 次に、ワークフローをテストしてみましょう。\n\n1. リポジトリ名の下にある ** \\[Issues]** をクリックします。\n\n ![リポジトリのメイン ページのスクリーンショット。 水平ナビゲーション バーでは、\\[イシュー\\] というラベルが付いたタブが濃いオレンジ色の枠線で囲まれています。](/assets/images/help/repository/repo-tabs-issues-global-nav-update.png)\n2. **\\[New issue]\\(新しい Issue)** をクリックします。\n3. \\[Add a title] には任意のタイトルを入力できます。\n4. \\[Add a description] のテキスト領域に、「`Hello`」と入力します。\n5. テキスト領域の下にある **\\[Create]** をクリックします。\n\nワークフローが完了するまでの時間が経過すると、新しいコメントが表示されます。 ユーザーのトークンを使っているため、コメントはユーザー自身によって作成され、あいさつ文が含まれます。\n\n## 次のステップ\n\nシークレット スキャンとプッシュ保護について詳しくは、GitHub Skills の「[シークレット スキャンの概要](https://github.com/skills/introduction-to-secret-scanning/tree/main)」コースをご覧ください。\n\nコード セキュリティのもう 1 つの重要な部分は、プロジェクト内のコードの脆弱性を特定して修正する方法を学ぶことです。 「[最初のコードの脆弱性を見つけて修正する](/ja/get-started/learning-to-code/finding-and-fixing-your-first-code-vulnerability)」を参照してください。"}