1. 計算を記述するものとアクセスを与えるものを分類する
まず、あなたのプログラムが実際に消費する情報から始めましょう。バッチサイズ、モデル名、処理モードは体験を記述するものです。ダウンロードを許可するトークンやストレージを開く鍵はアクセスを提供します。前者の集合は説明可能であるべきで、後者は必要な場所でのみ利用可能にしておくべきです。
境界は変数名だけにとどまりません。パスがクライアントを露呈することがあり、URLが識別子を内包することがあり、少量のデータサンプルが機密であることもあります。したがって、共有可能なパラメータの内容も評価してください。設定を公開することと、その絶対パスをすべて公開することは同じ決定ではありません。
この表は作業用の分類を提示するものです。Kernodeckのマシンにインストールされたサービスを記述するものではありません。プロジェクトごとに、各要素を誰が、いつ、どのコピーで読めるかを定義してください。その決定をノートブックの最後のエクスポートに委ねてはいけません。
表をスクロールしてすべての列を表示してください。| 要素 | 役割 | 提案される処理 |
|---|---|---|
| バッチサイズ、モード、しきい値 | 計算パラメータ | 値をバージョン管理し検証する。 |
| トークン、秘密鍵、パスワード | アクセス手段 | 別途提供し、出力に含めない。 |
| パス、URL、コーパス識別子 | 潜在的に機密性の高いコンテキスト | 共有前に確認する。論理的な識別子を優先する。 |
| 結果とログ | 実行の証跡 | 保持するフィールドを選択し、送信するフォルダを制御する。 |
2. 単一の優先順位ルールを選ぶ
コード内、ファイル内、そして起動オプション内に存在するパラメータは、どれが優先されるか誰も分からなければ曖昧になります。例えば、文書化されたデフォルト値、次に設定ファイル、次にコマンドの公開オプションといった単純なルールを定めてください。これはあなたのアプリケーションの契約であり、Pythonが提供する普遍的な優先順位ではありません。
この解決の後に検証します。batch_szieのような誤字が黙ってデフォルト値に置き換えられないよう、未知のキーは拒否してください。整数、整数を表す文字列、および真偽値を区別します。次に、有用な制約を追加します。正の値、許可されたモード、一貫性のあるパラメータの組み合わせです。
最後に、許可されたフィールドに限定した実効設定を記録します。これは、オプションがファイルを置き換えた場合でも、プログラムが何を使用したかを説明します。既知のパスワードをいくつか取り除く前に設定オブジェクト全体をシリアライズしてこの文書を得るのではなく、まず何を含めることができるかを選んでください。
3. サービスに接続せずに例を試す
次の例は教育目的であり、実行されるものではありません。8要素のバッチでベクトルを生成する架空の操作を説明しています。ここでの embedding という語はインターフェース上の選択であり、モデルはロードされず、GPU 依存関係がインストールされていることも想定していません。このファイルを読んだり検証したりするのにシークレットは必要ありません。
Python 3.11以降で利用可能な標準モジュールtomllibは、TOML形式を読み取ります。これは文書の値をPythonオブジェクトに変換しますが、バッチがゼロであることがあなたのアプリケーションで禁止されているかどうかを判断するものではありません。ドメインの検証は読み取り後も明示的に行います。
この抜粋は正確に2つのキーと2つのモードを受け付けます。プロジェクトで使用するには、続いて引数、エラー処理、出力パスを接続してください。想定される拒否は容易に推論できます：batch_size がゼロ、batch_size が文字列、または token キーの追加です。これらはご自身の環境で確認すべきケースであり、ここで計測された結果ではありません。
batch_size = 8
mode = "embedding"import tomllib
with open("config.toml", "rb") as source:
config = tomllib.load(source)
if set(config) != {"batch_size", "mode"}:
raise ValueError("CONFIG_KEYS")
if type(config["batch_size"]) is not int or config["batch_size"] <= 0:
raise ValueError("CONFIG_BATCH_SIZE")
if config["mode"] not in ("embedding", "classification"):
raise ValueError("CONFIG_MODE")
public_config = {
"batch_size": config["batch_size"],
"mode": config["mode"],
}4. 秘密情報は必要なステップにのみ提供する
既に存在するファイルを扱うステップは、ダウンロードトークンを要求してはなりません。シークレットは、アクセスが必要になる境界で要求してください。このステップが有効になっているのにアクセス手段が欠けている場合は、期待されるチャネルを示すメッセージを添えて停止し、受け取った値を表示したり、リクエスト全体をコピーしたりしないでください。
チャネルは利用可能な環境によって異なります。シークレットマネージャー、アクセスを制限した認証情報ファイル、あるいは組織が用意した注入の仕組みなどです。環境変数をインターフェースとして使うこともできますが、それはプロセスからアクセス可能なデータであり、診断情報に現れる可能性があります。注入の手軽さと完全な保護を混同しないでください。
アクセスは必要な範囲に限定し、その交換を想定しておいてください。ソフトウェアの準備を要求しても、シークレットマネージャーの存在が保証されるわけではありません。実際に利用可能な仕組みを確認してから起動方法を組み立て、必要としないサブプロセスにシークレットを渡すのは避けてください。
5. 入力をコピーせずに有用なログを設計する
いくつかのイベントを定義しましょう。設定の受理、ファイルの検査、パーティションの完了、出力の検証などです。それらに実行 ID、ステップ、カウンターを対応付けます。CONFIG_BATCH_SIZE というエラーがあれば該当するルールを特定できます。ファイル全体を含める必要はありません。
OWASP は、パスワード、アクセストークン、鍵などをログから除外することを推奨しています。このルールは例外、デバッグ用に表示するオブジェクト、セルの出力にも適用してください。最後の画面でマスクしても、既にファイルやキャプチャに書き込まれたものは消えません。
インシデントを共有する際は、小さな抜粋を用意しましょう。有用なバージョン、許可されたパラメータ、エラー、問題を再現する合成例などです。フォルダ全体を自動でアーカイブするのは避けてください。URL、ヘッダー、パス、エラー周辺の行も見直してください。一見無害なメッセージの周囲に機密データが含まれていることがあります。
6. 共有する前に分離を検証する
3つの試行を用意します：リモートステップなしの有効な構成、無効な構成、存在しないアクセスを要求するステップ。1つ目は不要なシークレットなしでその機能的境界まで到達できる必要があり、残り2つは異なるエラーを返す必要があります。また、公開されたバッチサイズの変更が実効構成に反映されることも確認してください。
共有手順を検証するには、明らかに架空でアクセス権限のないセンチネル文字列を使用してください。隔離された演習でシークレットと同じ場所に通し、その後、ログ、エクスポート、選択したファイル内でそれを検索します。それが見つからないことはこの経路における限定的な検証であり、あらゆる漏洩が不可能であることの証明ではありません。
適切なプライベートファイルを Git の除外設定に追加しますが、既に追跡されているファイルも確認してください。Git のドキュメントによると、gitignore は未追跡のファイルを対象としています。パターンを追加しても、既に記録されたシークレットは削除されません。除外するはずのルールだけでなく、実際に送信する内容を確認してください。
7. 拡散への対応と活用可能な記録の保持
アクセス情報が漏えいした場合は、その使用を直ちに中止し、発行元のシステムに対して失効または交換を依頼してください。現在のファイルから該当行を削除しても、以前のコピーが無害になるわけではありません。影響を受ける箇所を特定し、削除可能なものは削除するとともに、漏えいの範囲を把握してください。
再現可能なフォルダには、使用したチャネル名と許可されたパラメータを残し、シークレット自体は保持しないようにできます。将来の起動時には、適切なタイミングで有効なアクセス手段を要求します。こうすることで、実験のアーカイブをアクセス手段の束に変えることなく、引き継ぎ可能な手順が得られます。
この方法は、あなたのアプリケーションとその成果物を対象としています。環境全体の分離や、他の場所に技術的な痕跡が残らないことを保証するものではありません。実行に移す際は、文書化された環境、管理されたデータ、そして進捗と検証済みの結果を区別する追跡と組み合わせてください。