既存の権限を通過した対象操作を別のモデルが依頼と照合します。人の承認が必須の操作は残り、自動承認は確認した操作と引数に一度だけ適用されます。 承認回数の削減と権限付与を混同しない設計が焦点です。監査では承認記録に加え、権限判定、会話、接続先の実行結果を照合します。 確認の連続で重要な判断を埋もれさせない AWSは11月4日、Amazon QuickのSmart Approvalsを使う際の統制と監査を解説しました。許可された操作でも、人の判断が必要になる場合があります。一方、定型操作のたびに確認が続くと、重要な承認への注意が弱まる可能性があります。Smart Approvalsは、既存の管理を通過した対象操作について、利用者の依頼に合うかを確認します。自動的に認めるか、利用者へ戻すかを判断する仕組みです。追加の権限を付与したり、必須の人手承認を取り除いたりするものではありません。権限の境界と、その内側での判断を別の役割として設計しています。 別モデルの判断を一回の操作へ限定する 対象となるのは、利用者の設定が都度確認であり、ほかの管理が人手承認を要求しない操作です。分類用の別モデルが、依頼と限られた会話の範囲を照合します。何を行い、どこへデータを送り、誰に影響するかを考慮します。接続資料に書かれた追加の送信先などは、依頼を超える行動として扱う例が示されています。自動承認は確認した操作と引数に一度だけ有効で、継続的な許可にはなりません。判断が拒否された場合や時間切れなどの失敗時は、利用者へ確認を返します。原文は、モデルの判断が誤ることもあると明記しています。機密情報の移動など必ず人が見るべき操作は、コネクターの権限で明示する必要があります。最終的な権限の強制はモデルとは別の仕組みが担います。 承認されたことと実行されたことを区別する CloudTrailには、利用者、接続先、操作、時刻などを含む関連記録が残ります。ただし、Smart Approvalsの記録があるだけでは、許可が受理され、操作が完了したとは確認できません。会話ログ、権限判定、接続先の送信済みメールや更新済みチケットなどを照合します。長期の調査にはTrailの設定が必要とされ、会話ログは配信設定後の活動だけを記録します。運用側では、開始前に必要な証跡が残るかを確認することが論点です。記事は、限定したチームと業務で試行し、自動承認の標本を確認するよう勧めています。確認回数だけでなく、重大な操作が人に戻るか、承認から実行まで追跡できるかを評価する構成です。接続先側の証跡も欠かせません。 既定の有効化と利用者の選択を確認する Smart Approvalsは既定で有効ですが、拒否を基本とする権限設定では明示的な許可が必要です。利用者自身が無効にした場合、アカウントの設定でそれを覆して有効化することはできません。その選択は会話と定期実行に適用されます。管理者には、利用可能な人を絞る設定と、常に人の承認が必要な操作を分ける作業が残ります。機能を使えることだけで統制が完成するわけではなく、ログの準備と試行結果を合わせて拡大を判断することが焦点になります。