シェア:
){kind=small}
Benjamin AronovはVonageの開発者支援者です。彼はRuby on Railsのバックグラウンドを持つ実績のあるコミュニティ・ビルダーです。Benjaminは故郷であるテルアビブのビーチを楽しんでいる。テルアビブを拠点に、世界最高のスタートアップの創設者たちと出会い、学ぶことができる。技術以外では、完璧なパン・オ・ショコラを求めて世界中を旅するのが好き。
Rails認証情報でRailsアプリを安全に：実践ガイド
所要時間：2 分
このステップバイステップの Rails アプリガイドでは、Rails Credentials を使用して Rails で API キーを安全に保存し、Vonage で RCS メッセージを送信します。
任意の Railsアプリケーションを構築するとき どこにという問題が出てきます。APIキー、プライベートトークン、サードパーティとの統合用の識別子など、小さいけれども重要な、ソースコードに書くべきでないものばかりです。前回の記事 Rubyで環境変数を使うでは、環境変数について、そしてなぜ開発者が環境変数を多用するのかについて説明した。
Rails には別の選択肢があります： Railsクレデンシャルこれは暗号化された、アプリケーションネイティブな秘密管理方法です。Railsクレデンシャルは、機密データを安全に保存する場所を提供しつつ、そのデータを開発およびデプロイのワークフローを通じて摩擦なく移動できるように設計されています。その仕組みを理解すれば、特にVonageが提供するようなAPIを統合する場合、Railsアプリを構築する上で自然に利用できるようになります。
この記事では、Railsクレデンシャルがどのような位置づけにあるのか、環境変数とどのように異なるのか、そしてRailsアプリケーション内でVonage APIキーを安全にロードするためにクレデンシャルをどのように使用できるのかについて説明します。最後には、シンプルなRailsアプリに次のようなサンプルを組み込んでみましょう。 RCSテキストメッセージの送信.
始めよう。
Railsクレデンシャルは、APIキー、サービストークン、プライベート証明書、その他プレーンテキストでは保存すべきでない設定のような、機密性の高いものを保存するためのRails組み込みの暗号化ストレージメカニズムです。Rails 5.2で導入されたこの機構は、アプリケーション開発における一般的な緊張に対処するために導入されました。 アプリケーション開発における共通の緊張に対処するために、Rails 5.2で導入されました。アプリケーション開発における共通の緊張に対処するために、Rails 5.2で導入されました。
ここがRailsクレデンシャルが環境変数と根本的に異なる点です。環境変数はリポジトリに一切保存されません。開発者、サーバー、デプロイ環境ごとに独自のコピーが必要で、通常はシェルプロファイル、ホスティングダッシュボード、CIシステムで設定します。このアプローチはうまくいくが、オーバーヘッドを伴う。値が変更されると、それが使用されるすべての場所で再配布されなければならず、それらの値の同期を保つのはチーム次第だ。
Railsクレデンシャルは異なるアプローチをとります。シークレットは暗号化されたファイルに保存され リポジトリにに保存されます。一致するマスターキーがなければ復号化できないため、ファイル自体は安全にコミットできます。シークレットへのアクセスは、個々の値を手動で共有するのではなく、そのキーへのアクセスによって制御されます。
実際には、これはチームのワークフローを簡素化する。Vonage APIシークレットのローテーションや秘密鍵の再生成が必要になったとしよう。環境変数では、新しい値をすべての開発者とそれに依存するすべての環境に安全に配布する必要があります。Rails Credentialsでは、暗号化されたクレデンシャルファイルを一度更新し、変更をコミットしてプッシュします。マスターキーをすでに持っている人は、アップデートをプルして、追加設定なしで作業を続けることができます。
重要なアイデアは、Rails Credentialsが秘密の 変更を秘匿しながら アクセスを制限することです。平文の値ではなく、暗号化されたデータをバージョン管理することで、マシン、シェル、受信トレイに設定を分散させることなく、長期的な更新を管理しやすくなります。
Railsが何を達成しようとしているのかがわかると、ワークフローがより理解しやすくなります。実行すると
rails credentials:edit通常のYAMLファイルは得られません。Railsは認証情報の復号化されたコピーを開きます。 メモリ上のを開きます。ディスク上では、実際のファイルは完全に暗号化されたままです。保存してエディタを閉じると、Railsは更新された内容を自動的に再暗号化します。これは安全な小さなループです: 一時的に暗号化を解除し、安全に編集し、再び暗号化します。
その結果が、Railsに直接組み込まれたロックボックスです。予測可能で、バージョン管理され、デフォルトで暗号化され、ログに漏らしたくないものや、うっかりSlackに貼り付けて「これ他の人にも使える？これは、特にリポジトリベースのワークフローからデプロイするときに便利だ。Heroku, レンダー, Fly.ioなど）で、コードとインフラが一緒に動く。
Rails Credentialsの背後にある考え方を理解すれば、仕組みはすぐに理解できます。すべての中心は暗号化されたファイルです： config/credentials.yml.enc.このファイルがまだ存在しない場合、クレデンシャルを最初に編集したときにRailsが生成します。値を追加するまで、このファイルはディスク上に暗号化されたまま残ります。
このファイルと対になっているのがマスター・キーで、通常は次の場所に保存されている。 config/master.key.Railsはこの鍵を使って認証情報を編集したり、実行時に読み込んだりします。マスターキーにアクセスすると、保存されているすべての秘密へのアクセスが事実上許可されるため、Gitでは意図的に無視されています。Railsは、デプロイ環境または別の安全なチャネルを通じてこのキーを提供することを想定しています。
走るときにね：
EDITOR="code --wait" rails credentials:editRailsはマスターキーを使用して資格情報ファイルを復号化し、エディタで一時的に復号化されたコピーを開き、保存して閉じるとすぐに内容を再暗号化します。復号化されたバージョンはメモリ上にのみ存在し、ディスクに触れることはありません。
>>注意注意 bin/railsを使うことで、コマンドはプロジェクトの正確なRailsバージョンに対して実行されます。 --waitフラグがVS Codeに必要なのは、編集を終える前にRailsが資格情報ファイルを再暗号化しないようにするためです。
覚えておくべき主なルールは単純で、暗号化されたファイルはリポジトリにコミットできますが、マスターキーはコミットできません。システムはこの2つの部分を別々に保つことに依存しています。
Railsは環境固有の認証情報もサポートしています。実行することで、暗号化されたファイルと鍵を完全に分離して管理できる：
rails credentials:edit --environment productionこれは config/credentials/production.yml.encを開きます。を開きます。それぞれの環境は独自のキーと独自のシークレットセットを保持します。本番環境のクレデンシャルはローカルで使われるものから分離された状態を保つ必要があるので、これは重要です。
日々の開発では、この多くは背景に隠れてしまいます。あなたはYAMLを書き、Railsはそれを暗号化し、アプリケーションは余計なセレモニーなしに実行時にそれを読み取ります。暗号化されたファイル1つ、キー1つというシンプルなアプローチです。そしてRailsなので、複雑な処理はほとんど1つのコマンドで処理されます。
Railsクレデンシャルがいかに簡単で強力かを示すために、RCSテキストメッセージを送信する簡単なRailsアプリケーションを作成します。
VonageアカウントでRCSを有効にしていない場合、またはテスト用のRCS対応機種をお持ちでない場合は、RCSをSMSやWhatsAppに置き換えてもほぼ同じフローでご利用いただけます。
Vonage APIアカウント
RCS対応の電話番号と RCS対応アカウント(またはSMS/WhatsAppへのフォールバック)
Rails Credentialsを使って何かを保存する前に、値そのものが必要です。RCSメッセージングでは、Messages APIを使ってVonageアプリケーションを作成することになります。
Vonage Dashboardでアプリを作成します。アプリに名前を付け、メッセージ機能をオンにします。
アプリケーションを作成するには アプリケーションの作成ページでアプリケーションの名前を定義します。
Webhooksを使用するAPIを使用する場合は、秘密鍵が必要です。Generate public and private key "をクリックすると、自動的にダウンロードが始まります。この鍵は紛失すると再ダウンロードできません。この鍵は紛失しても再ダウンロードできません。 private_<あなたのアプリID>.key.この鍵はAPIコールの認証に使用できます。 注意：アプリケーションを保存するまで、キーは機能しません。
必要な機能（Voice、Messages、RTCなど）を選択し、必要なWebhook（イベントURL、応答URL、受信メッセージURLなど）を提供します。これらはチュートリアルで説明します。
保存してデプロイするには、"Generate new application "をクリックして設定を確定します。これでアプリケーションはVonage APIで使用する準備が整いました。
RCSアプリの要件
インバウンドURLとステータスURLをプレースホルダーエンドポイントに設定する。
ボタンをクリックして、公開鍵と秘密鍵を生成します。
変更を保存する
次に、"Link external accounts "タブをクリックして、RCS Agentをリンクします。
この時点で、Railsプロジェクトには3つの値が用意されているはずです：
アプリケーションID
秘密鍵ファイル
RCS送信者ID
Vonage Dashboard showing an application configured for RCS messaging, including linked external RCS accounts and application credentials.
Vonageアプリケーションをセットアップし、キーを手に入れたら、チュートリアルのRailsパートに移ります。ここでの目標は、Railsクレデンシャルが実際のアプリケーションのワークフローにどのように自然に適合するかを示すことです。シンプルにするために、POSTリクエストで渡した電話番号にRCSテキストメッセージを送信するエンドポイントを1つ持つ最小限のRailsアプリを作成します。
新しいRailsアプリケーションを作成し、Vonage SDKを追加することから始めます：
rails new rails_credentials_rcs_demo --api
cd rails_credentials_rcs_demobundle add vonage(を使用する --apiフラグを使うとプロジェクトは軽量になりますが、フルスタックのRails環境を好む場合はオプションです)。
次に、Vonageの認証情報をRailsに読み込みます。暗号化されたクレデンシャルファイルを開きます：
EDITOR="code --wait" bin/rails credentials:editダッシュボードからYAMLをVonageアプリケーションの値に更新します：
vonage:
application_id: "<YOUR_APPLICATION_ID>"
private_key: |
-----BEGIN PRIVATE KEY-----
<contents of private_<app-id>.key here>
-----END PRIVATE KEY-----
rcs_sender_id: "<YOUR_RCS_SENDER_ID>"保存してエディタを閉じます。Railsがすべてを自動的に再暗号化し、認証情報が から利用できるようになります。.
>>注意秘密鍵をクレデンシャルに追加する場合、鍵の各行が以下のように一貫してインデントされていることを確認する。 の下で一貫してインデントされていることを確認してください：-インデントが正しくない場合、YAMLのパースエラーが発生します。
秘密が揃ったので、RCSメッセージを送信するための単一のルートとコントローラを作成できる。
エンドポイントのルートを追加する：
# config/routes.rb
post "/rcs_messages", to: "rcs_messages#create"次にコントローラを生成する：
rails generate controller RcsMessages --no-helper --no-assets --skip-routesそして、Vonage Ruby SDKを使用してRCSメッセージを送信するロジックで更新します：
# app/controllers/rcs_messages_controller.rb
class RcsMessagesController < ApplicationController
def create
to = params[:to]
text = params[:text] || "Hello from Rails + RCS"
client = Vonage::Client.new(
application_id: Rails.application.credentials.dig(:vonage, :application_id),
private_key: Rails.application.credentials.dig(:vonage, :private_key)
)
client.messaging.send(
message_type: "text",
channel: "rcs",
to: to,
from: Rails.application.credentials.dig(:vonage, :rcs_sender_id),
text: text
)
head :ok
end
end
>>注RCSでは rcs_sender_idは通常ブランド名（例えば 「Vonage "などなど）である。
このコントローラは、Railsの構造やメッセージの永続性よりもクレデンシャルのワークフローに焦点を当てられるよう、意図的に最小限にとどめています。POSTリクエストで電話番号とオプションのテキスト文字列を渡すと、エンドポイントがRails Credentials内で暗号化した値を使用して認証済みのRCSメッセージを送信します。エンドポイントは digメソッドメソッドはネストされたデータにアクセスするのに非常に便利です。
Railsアプリケーションを起動します：
rails sテストするには、ターミナルで新しいタブを開く。そして、単純な curlリクエストを実行する：
curl -X POST http://localhost:3000/rcs_messages \
-d 'to=447700900000' \
-d 'text=Hello from Rails!'
舞台裏では、Railsが起動時に認証情報を復号化し、Vonage Ruby SDKがアプリケーションIDと秘密鍵を使用してJWTを作成し、Messages APIがRCSメッセージを指定した番号に送信します。
この小さな例では、秘密の安全な保存、Rails環境への読み込み、ソースコードや設定ファイルに機密値を公開することなく実際の統合で使用する、というライフサイクル全体をキャプチャしています。
最終的には、どのRails開発者もローカル設定だけでは不十分で、実際の環境でアプリケーションを実行する必要があるという段階に到達します。本番環境では独自の暗号化ファイルとマスターキーが必要になるためです。
プロダクション認証情報を編集するには、次のコマンドを実行する：
rails credentials:edit --environment productionRailsは暗号化されたファイルを以下の場所に作成する（または開く）： config/credentials/production.yml.enc
で対応するマスターキーを期待する：
config/credentials/production.key
開発では、Railsはこのキーをファイルシステムから自動的に読み取ることができます。しかし本番環境では、アプリケーションが起動時に認証情報を復号化できるように、ホスティング環境を通じてマスターキーを提供する必要があります。
正確な方法はプラットフォームによって異なる：
レンダリング: セット rails_master_keyを設定する
Fly.io： fly secrets set RAILS_MASTER_KEY=...
Heroku: アプリのconfig varsに追加する。
VPSまたはカスタムサーバー：環境またはsystemdユニットでエクスポートします。
Railsは正しいキーがないと起動しないので、アプリケーションを実行する場所にキーがあることを確認することが重要です。
つのガイドラインは強調する価値がある： 各環境には独自のマスターキーが必要だ。開発環境、ステージング環境、そして本番環境は、安全性と明確性の両方から、互いに分離されたままであるべきです。これらのキーを分離しておくことで、コンフィギュレーションが所属する環境にスコープされたままになり、センシティブな値への偶発的なクロスエンバイロメントアクセスを防ぐことができます。
本番用のマスターキーが設定されると、あとはRailsが処理します。Railsは起動時に認証情報を復号化し、開発時と同じようにアプリケーションで利用できるようにします。
Rails Credentialsは複雑な問題のほとんどを解決してくれますが、開発者が時々ぶつかる問題もいくつかあります。以下は最も一般的な問題とその対処方法です。
マスターキーの誤操作
マスターキーがGitに紛れ込んだ場合は、それを公開鍵として扱う。影響を受ける秘密をローテーションし、新しい鍵を生成し、元の鍵がバージョン管理の履歴から削除されるようにしましょう。暗号化されたファイルが安全なのは、マスターキーが非公開のままである場合だけです。
暗号化ファイルのコンフリクトをマージする
暗号化されたファイルには意味のある構造が含まれていないため、Gitはファイル内の衝突を解決することができません。複数の人がクレデンシャルを編集する必要がある場合は、それらの変更を調整するか、環境固有のクレデンシャルや外部のシークレットマネージャーに依存して衝突を避けましょう。
認証情報が本番環境でロードされない
これは通常 rails_master_key環境変数がないか、クレデンシャルファイルの暗号化に使用されたキーと一致しないことを示しています。ホスティング環境で正しいキーが設定されていること、正しい暗号化ファイルに対応していることを確認してください。
破損した暗号化ファイル
まれではあるが、暗号化されたクレデンシャルファイルが読めなくなることがある。それを再生成するには
rm config/credentials.yml.enc
rails credentials:editファイルを再生成した後は、必ず値を再入力してください。元のデータとキーがないと、以前の内容は復元できないからです。
Railsクレデンシャルは多くのアプリケーションに適していますが、シークレット管理に対する万能の回答ではありません。環境によっては、従来の環境変数がより適切な選択肢であることに変わりはありません。
環境変数は、コンテナベースやマルチサービスのアーキテクチャにデプロイするときに、リポジトリに保存するのではなく、実行時に設定を注入する必要がある場合にうまく機能する。また、Kubernetes、ECS、Nomadなどのオーケストレーションシステムで作業する場合や、ビルド中やテスト実行中にシークレットへのアクセスが必要なCI/CDパイプラインを実行する場合にも、標準的なオプションとなります。また、Rails以外の複数のサービスが同じ設定値を共有する場合、環境変数を使用することでスタック全体で一貫した設定を維持できます。
一方、Rails Credentialsは、Railsエコシステム内にとどまるアプリケーションに自然に適合します。複数の .envファイルや外部のシークレットストアを管理するオーバーヘッドなしに、機密データの暗号化されたバージョンストレージを提供します。また、Gitリポジトリから直接デプロイし、アプリケーションが独自の設定を提供することを期待するプラットフォームともスムーズに統合できます。
多くのプロダクションセットアップでは、インフラストラクチャのレベルでは環境変数を使用し、アプリケーション固有の秘密にはRails Credentialsを使用するという、両方のアプローチを組み合わせています。適切な選択は、システムの構造と、設定をどこに置く必要があるかによって決まります。
Railsのクレデンシャルは、セキュリティと保守性を念頭に置きながら機密設定を扱うためのわかりやすい方法を提供します。暗号化された値をアプリケーションと一緒に保存し、環境固有のキーに依存することで、設定を複数のファイルやシステムに分散させることなく秘密を管理するための信頼できるパターンを得ることができます。
Vonage Ruby SDKと組み合わせることで、このアプローチは実際のRailsワークフローにうまくフィットします。アプリケーションは、ソースコードやシェル環境でAPIキーやプライベートキーを公開することなく、安全に認証し、RCSメッセージを送信し、Messages APIとやり取りすることができます。その結果、実用的でセキュアなセットアップが実現し、アプリケーションの成長に合わせてうまく拡張できるようになります。
ご質問がある場合、またはあなたが作っているものを共有したい場合は、こちらをクリックしてください。
登録する 開発者ニュースレター
フォローする X（旧ツイッター）最新情報
チュートリアルを見る YouTubeチャンネル
LinkedInの LinkedIn の Vonage デベロッパーページ
最新の開発者向けニュース、ヒント、イベント情報をお届けします。