公開日：
汎用AI自動要約
インターネット上にはWordPressなどのCMS利用に関するセキュリティ懸念が散見されるが、脆弱性があるからといって一律に禁止すべきではない。静的サイトやデータベース廃止で攻撃リスクを減らせる一方で、全てのソフトウェアは継続的保守が必要であり、脆弱性対応の体制が重要。AIの利用で攻撃の自動化も進む中、機能の動作・危険性・対応策を理解し、適切に運用・管理する知識が今後さらに求められる。
SNSを見ていると，情報系の記事が目立つ（ように感じる）。
それらの記事にやや偏りがあるようにも思う。
例えば，
- 「WordPressは脆弱性があるので危険」
- 「動的Webサイトから，静的Webサイトに切り替えました」
- 「DBを廃すことで，ハッキングの可能性を減らしました」
など。
こういったのを見ると，「ん？」とは思う。
確かに，静的Webサイトに切り替えたり，
DBを廃したりすることで，攻撃される可能性のある箇所を減らすことはできる。
ただ，それを理由として
「WordPressは危険だから使うべきではない」
とするのは，少し違うだろう。
（WordPressを例に挙げているが，RailsでもLaravelでも，CakePHPでも何でもよい。）
確かにCMFなどフレームワークには脆弱性が見つかることがある。
しかし，「脆弱性が皆無」と断言できるプログラムなどあるのだろうか。
ApacheやNginxだって，都度リリースされているし，Node.jsも同じである。
もちろん，マイナーアップデートのすべてが脆弱性への対応というわけではないが，
ソフトウェアには継続的な保守が必要となる。
とくに，クローズな環境で動くアプリではなく，
インターネットに接続して運用する以上，
何かしらの脆弱性が発見される可能性はある。
それらに都度対応していく必要がある。
一方で，閲覧するだけのWebサイトであれば，
静的Webサイト（固定ファイル）にするのも合理的だろう。
それらが必要なのであれば，適切な対策を講じたうえで利用すればよいと思う。
ここ数日，情報漏洩のニュースをよく目にする。
今後は，AIエージェントを用いて，
攻撃の準備や実行を自動化するような事例も増えていくのだろう。
ただ，総当たり攻撃などは，以前から自動化されている。
Linuxであれば，Fail2banを適切に設定しておくことで，
特定のIPアドレスから繰り返される認証試行などを，ある程度防ぐことはできる。
もちろん，Fail2banだけですべての攻撃を防げるわけではなく，
複数の対策を組み合わせる必要がある。
要は，「脆弱性が生じる可能性があるから使うな」ではなく，
「必要なものは使う。
そのうえで，生じうるリスクを理解し，問題が発見された場合に対応できるようにしておく」
ことが大事に思う。
もちろん，先の不要な機能を最初から持たないという設計も，一つの方法である。
「ドメイン知識」の話もあったが，AIエージェントが広く色々とやってくれる今，
プログラムの内部実装をすべて理解する必要はないのかもしれない。
しかし，
- 「今，どのような機能が動いているのか」
- 「それぞれの機能には，どのような危険性があるのか」
- 「問題が生じた場合に，どのように対応すればよいのか」
といったことぐらいは，知っておいた方が望ましいだろう。
AIエージェントがプログラムを作ってくれる時代だからこそ，
それをどのように「運用」し，
「管理」していくかという知識が，
より重要になっているように思う。