dosya APIキーの最終使用を確認する
APIキー一覧の最終使用を大まかな活動の手がかりとして使い、使用元のクライアントと照合して、未使用と確認できてから取り消します。
最終確認日
スクリーンショットは英語版の画面です。
最終使用列は認証情報の管理に役立ちます。遅れて反映される活動の手がかりであり、個々のリクエストの監査記録でも、クライアントが廃止された証拠でもありません。

一覧に表示される情報
**プロフィール → API(APIキー)**を開いてください。各行に名前、権限、プロトコル、アクセス範囲、最終使用が表示されます。行を展開すると、作成日、有効期限、IP許可リスト、使用可能な時間帯、マスクされたキーのフィンガープリントも表示されます。
Neverはサーバーにlast_used_atの値がないことを意味します。最後に記録された使用から90日を超えると、概要にはキーが90日以上未使用と表示されます。一度も使われていない認証情報は、代わりにcreated_atを基準に判定されます。
手順
- キーの名前またはマスクされたプレフィックスで検索し、似た名前の認証情報と取り違えないよう、該当する行を展開してください。
- 権限、プロトコル、アクセス範囲、作成日、有効期限、制限の詳細を、担当者が管理するクライアントの一覧と照合してください。
- 最終使用をおおよその日時として確認し、90日間使用されていないことを示す表示があるか確認してください。
- シークレットを診断情報にコピーせずに、連携側のログとdosya APIキーの分析で、想定される最近の呼び出しを確認してください。
- まずクライアント側で認証情報を無効化または置き換え、定期実行や使用頻度の低いジョブに合わせた期間、使用がないことを確認してください。
- 担当者を特定してから招待を取り消すを選択してください。この操作により、選択したAPIキーが無効になります。元に戻せないことを示す警告を確認し、クライアントで予期しない拒否が起きないか監視してください。
値の反映が遅れる理由
REST、SFTP、WebDAV、S3はlast_used_atをバックグラウンドで可能な範囲で更新します。SFTPは分類済みのゲートウェイリクエストを通じてRESTミドルウェアに到達するため、受け入れられた通信は同じキーフィールドを更新します。書き込みは稼働中の各isolateでキーごとに15分間に最大1回に制限されます。そのため、リクエストが成功しても表示値がすぐに変わるとは限らず、別のisolateはそれぞれの時間枠で書き込みます。
正確なリクエスト履歴が必要な場合は、分析またはアプリケーション側の記録を使用してください。最終使用は確認する候補を探すための情報であり、使用がなかったことの証明にはなりません。
期待される結果
長期間使用されていないキーや想定外のキーごとに担当者が特定され、クライアント側の記録を確認できます。取り消した行は、停止が確認された連携または代替の認証情報への移行が完了した連携のものだけになります。

関連ガイド
この記事は役に立ちましたか?
評価の結果を読み込んでいます…
投票すると、回答を変更できるように、必要な投票用Cookieが最長180日間保存されます。
質問と回答
このガイドの手順について質問できます。質問は確認後に公開されます。
公開の質問には、アカウントの詳細、認証情報、非公開ファイルを含めないでください。これらについては 非公開サポート をご利用ください。
質問を読み込んでいます…
dosyaアカウントにサインインすると、質問を投稿できます。