curlでPOSTしてページからバッチ処理を行うのはセキュアな設計でしょうか？

Question

いま定時実行するバッチ処理の設計をしているのですが、設計がセキュアかどうか質問させてください。
また、セキュアでない場合はどのような設計が望ましいのか教えていただけると幸いです。

フレームワークで構築したWebサイトを稼働しています。
そのWebサイト内からcronで定期的にcurlを実行し、自サイトの特定のページにPOSTします。
POSTされたページからビュー内でバッチ処理的にDBにアクセスする処理を書きたいと思っています。

このページへの第三者からのアクセスを禁止したいので、POSTのデータにキーを設定して、キーが違う場合は404エラーを出力するようにします。
キーが一致する場合はバッチ処理を実行します。

想定される攻撃はPOSTによるブルートフォースアタックですが、キーの長さは十分に長くする想定です。
この設計にした理由は、フレームワークとcronで定時実行するバッチ処理を書きたい場合、この方法が簡単だからです。

この設計には何か問題がありますか？

Answer 1

「設計がセキュアであるかどうか？」は、その元となる「セキュリティ要件が適切に設定され、それを正しく設計に落とし込めているか？」と言いかえることができます。

提示されているセキュリティ要件は「ブルートフォースアタックに一定以上の強度を持つこと」のみなので、この質問からは正しく判断できません。

もしコレ以外に要件がないのであれば、セキュリティ要件の設定に失敗しています。

自己解決内容に関して
「フレームワークとcronで定時実行するバッチ処理を行う」といった要件に、「cli コマンドを cron で叩く」という実装はそれほどおかしなものではないですが、前提となる要件が適切に設定されているように思えません。
これは、Web API を叩く実装が歪なためで、この発想が出たのであれば、なんらか別の要素があるのではないかと推測されます。

もう一度、要件定義から整理し直してみてはいかがでしょうか？

Comments

[退会済みユーザー]

セキュリティ要件を定義した経験がないのですが、今回の場合は「第三者からバッチ処理が実行されないようにする」というのが肝心な部分です。
APIをネットに公開する場合、キーで制限をかけてもブルートフォースアタックが可能なので、セキュリティ的には難点がありました。また、通信が暗号化されていない場合は盗聴されるリスクもありました。
APIをネットに公開せず、システム内からフレームワークのコマンドを実行する場合は、外部にコマンドのインターフェースを公開する必要もないので、よりセキュアであると判断しました。

Answer 2

APIではなくフレームワークのコマンドをバッチ処理に使うのがよりセキュアみたいなので、自己解決します。