セキュリティ、secrets、安全な運用

プロジェクトのローカル secrets

Lino は、生成されたアプリケーションに必要なローカル secrets を自動的に登録します。データベース、Redis、RabbitMQ のパスワード、JWT キー、API keys、その他の機密値は、バージョン管理されたファイルではなく、アプリケーションの User Secrets に保存されます。

lino secret list
lino secret set
lino secret remove
lino secret clear

これらのコマンドは保守にも役立ちます。secret list は構成済みキーの監査、secret set はローカル値の変更または登録、secret remove はキーの削除、secret clear はプロジェクトのすべてのローカル secrets の削除に使用します。

このフローは生成されたプロジェクトに統合されています。Redis、RabbitMQ、認証、認可、SMTP、API keys、download tokens などのリソースを追加するとき、Lino は機密値をソースコードの外に保ち、アプリケーションがそれらを環境構成として受け取れるようにします。

必要に応じて、dotnet user-secrets list や同等の Aspire リソースなど、.NET と Aspire のプラットフォームツールでローカル secrets を確認することもできます。Lino のコマンドは、生成されたプロジェクトの文脈でこのフローをより直接的にするためにあります。

Aspire のパラメーター

Aspire AppHost は、データベース、Redis、RabbitMQ、API、worker、web app などのリソースを調整します。生成されたプロジェクトでは、Lino は機密値を Aspire パラメーターとして登録し、アプリケーションがそれらをソースコード内の固定データではなく外部依存関係として扱えるようにします。

これには、データベース、Redis、RabbitMQ のパスワードや、ローカルインフラに必要なその他の値が含まれます。AppHost は Aspire の secret モデルを使い、たとえば sensitive としてマークされたパラメーターで、これらの値を対応するリソースへ渡します。

実用上の利点は、secret が構成ファイルの中に埋もれた詳細ではなく、ソリューションの実行モデルの一部になることです。Aspire 経由でアプリケーションを実行すると、各サービスは必要な依存関係を受け取り、各プロジェクトへ手動でパスワードをコピーする必要がありません。

この設計は deploy にも役立ちます。Aspire が成果物を公開するときも、これらのパラメーターの必要性は残ります。たとえば Docker Compose では、正しい環境で埋めるべき placeholders や環境ファイルが現れることがあります。他の targets でも、同じ原則が機密構成をプラットフォームへ渡す方法を導きます。

Rate limiting

Rate limiting は、悪用、brute force、不適切なリソース消費を減らします。Lino は標準 policies を構成し、生成された endpoints に helpers を適用するため、公開、認証済み、内部、機密 API が利用制限なしで作成されることはありません。

これは重要です。API が正しく認証していても、大量アクセスによる悪用を受ける可能性があるためです。login、refresh token、サインアップ、パスワード復旧は機密性の高いフローです。Lino は既定でこれらを一般的な endpoints から分離し、より保守的な制限を持たせます。

• 新しい endpoints を作成するときは、生成された policies を使用します。
• 機密 endpoints と一般 endpoints で異なる制限を維持します。
• 必要に応じて rate limiting を認証、検証、bot 対策と組み合わせます。
• 制限を超えたときの期待される応答として 429 Too Many Requests を扱います。

JWT セキュリティ

認証を追加すると、Lino は JWT の発行、読み取り、検証の土台を生成し、署名キーをソースコードの外に保ちます。token はユーザーを識別し、JWT をポータブルなデータベースにすることなく、必要な claims だけを運びます。

• 開発時は署名キーを User Secrets に、本番環境では安全な provider に保持します。
• プロジェクトで構成された issuer、audience、有効期限、アルゴリズムの検証を維持します。
• 認証済みフローに必要な claims だけを含めます。
• multi-tenancy では、Lino がすでに提供している user と tenant の context を使用します。

JWT の署名キーは重要な secret であり、Lino はこの値をすでに機密構成として扱います。新しい環境、pipeline、deploy を作成するときも同じルールを維持してください。キーは commit、Docker image、log、公開ファイル、実際の構成例に現れてはいけません。

JWT はドメインの認可も置き換えません。claims は判断に役立ちますが、重要な操作では現在の状態、ユーザー状態、有効な権限、リクエスト context を引き続き考慮する必要があります。生成された部分は土台を提供します。システムを発展させるときの責任は、このフローを無視する近道を作らないことです。

API keys と download tokens

Lino は API keys と一時 tokens を、scope が限定された credentials として扱います。フローがファイル、パッケージ、統合への一時アクセスを解放する必要がある場合、生成された土台は広い credentials の再利用ではなく、短く具体的な tokens を優先します。

• links と一時 tokens には短い有効期限を使います。
• フローにその context がある場合、token を user、tenant、resource に関連付けます。
• 機密 artefacts へのアクセスを伴う場合は、監査のために使用状況を記録します。
• resource または permission が変わったときは tokens を取り消します。

key で保護された API は、Lino が生成した authorization と rate limiting のモデルを使用します。統合自動化のために作成された key が管理呼び出しの自由通行証になってはいけません。また、一時 download token が認証済みユーザーの permissions を置き換えてはいけません。

新しい download または統合フローを作成するときも、同じ考え方を維持してください。明示的な scope、有効期限、有用な metadata、適切な rate limiting policy です。これにより、一時アクセスはシステム内を漂う loose credential ではなく、監査可能で予測可能なものになります。

本番環境の secret providers

User Secrets はローカル開発を解決します。本番環境では、プラットフォームの安全な provider を使って同じ分離を維持します。Azure Key Vault、AWS Secrets Manager、Google Secret Manager、HashiCorp Vault、Kubernetes Secrets、または orchestrator によって保護された環境変数を使用します。

Lino は、アプリケーションがコードの外から機密構成を受け取れるように準備します。本番環境への移行は環境側の判断です。名前とパラメーターは存在し続けますが、値はインフラで使用する vault、pipeline、orchestrator から来るようになります。

本番環境では、rotation、環境ごとの分離、アプリケーションごとの権限、アクセス監査といった運用上の実践も必要になります。User Secrets はこれらの管理を置き換えません。secrets をリポジトリに置かずにローカル体験を支えるものです。

• 環境ごとに分離: development、staging、production は credentials を共有してはいけません。
• アプリケーションごとに分離: 各サービスは必要な secrets だけを受け取るべきです。
• rotation を計画: JWT keys、SMTP、API keys、データベースパスワードには交換手順が必要です。
• アクセスを監査: プラットフォーム上で secrets を読んだり変更したりできる人を記録します。