セキュリティの鉄則その1：今まさに違反しているかもしれません

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

これまでにSecurity Rule Zeroを何度も耳にして、覚えて そらで言えるようになっているはずです。もちろん、覚えていますよね？

念のため、もう一度確認しておきましょう。

ユーザー入力を決して信頼してはならない。絶対に。

よろしい。これで基本原則を確認できたので、セキュリティルールその1について説明しましょう。お気づきかもしれませんが、セキュリティのルールは1つだけではありません。それでは、ルールその1に進みましょう。

セキュリティルールその1：認証情報をハードコードしてはならない。絶対に。

APIで広く利用されているトークン化やフェデレーションIDによってアクセスを制御する現在、一般公開アプリでこのルールが破られることはほとんどありません。一方、このルールが頻繁に破られ、無視されているのは、組織の内部です。さらに、組織のデジタルトランスフォーメーション施策を支えるIT最適化に向けて、NetOpsがスクリプトと自動化の活用を進めるなか、これは急速に問題となりつつあります。

インターネット上で見つけた実例を1つご紹介しましょう。「1つ」としたのは、包括的なリストを提示する時間も帯域幅もないためです。それほどまでに、この慣行は広く浸透しています。

右側に示しているのは、非常によく見られる重大なセキュリティ上の過ち、すなわち認証情報を平文でハードコードすることです。実際の運用環境では許容できないことを認識している旨のコメントすらなく、より安全な認証方法を使用する必要性にもまったく触れていません。

NetOpsの観点では、共有の企業ネットワークに手を加えると影響範囲が大幅に広がるため、これは非常に憂慮すべきことです。

このようなセキュリティ上の問題が発生する理由の1つは、NetOpsが自動化を取り入れている一方で、必ずしも戦略的に導入しているわけではないことです。実際、かなりの割合のNetOps担当者がPythonを習得し、従来のCLIベースの構成・管理手法と組み合わせて使用しています。

コマンドラインで認証情報を入力するのと同じ感覚で、その認証情報をスクリプトに埋め込むだけで済ませてしまうのです。

いずれ、これは問題になります。誰かがこの慣行を悪用し、そのニュースが何日もフィードをにぎわせることになるでしょう。実際、同じようなことは以前にも起きています。覚えていますか？OneLoginの件です。認証情報を含むスクリプトではなく、認証情報を含むファイルを保存していました。それがどれほどの混乱を招いたかは想像に難くありません。

問題は、NetOpsがコマンドラインの認証情報をスクリプトに記述しても大丈夫だと考えているかもしれない一方で、そのスクリプトが最終的にどこに置かれるのかという点です。適切に管理されているでしょうか。Infrastructure as Codeのように扱われているでしょうか。バージョン管理され、リポジトリに保管されているでしょうか。

ご記憶にあるかもしれませんが、Network to Codeコミュニティの調査では、NetOpsでの導入率が高かったのは（意外にも……）Githubでした。

では、リポジトリがどこにあるのかを考えてみましょう。オフサイトでしょうか。それともオンサイトでしょうか。どのように保護されているのか、また、誰かに不正に取得された場合、影響はどこまで及ぶのでしょうか。

ビジネスの変化に対応し、そのニーズに応えるには、スクリプトと自動化によって運用を拡張する必要があります。NetOpsもその方向へ進まなければなりませんが、平文の認証情報をどこかに保存することの影響を十分に検討せずに進めるべきではありません。

最低限、スクリプトの実行時には認証情報の入力を必須とする必要があります。認証情報は、ファイルにもスクリプト内にも決して保存してはなりません。ましてや、平文で保存することは厳禁です。理想的には、より高度な認証情報管理ソリューションを使用して認証を必須とし、社内スクリプト全体でトークン化を利用します。しかし、現時点ではNetOpsにおける自動化の本格的な普及はまだ始まったばかりであり、一歩ずつ進める必要があります。

以上を踏まえ、少なくとも実行時には認証情報の入力を必須にしてください。現在の実装ではそれが難しすぎるのであれば、いったん立ち止まり、IT全体の自動化戦略を見直す時期かもしれません。まず問うべきは、自動化戦略があるかどうかです。それとも、現在行っていることは、ビジネス部門からの要求に対する場当たり的な（そして原始的な）対応にすぎないのでしょうか。

長期的な解決策として、すべてのスクリプトに認証情報を平文で記述するべきではありません。そもそも、そのような方法は成り立ちません。明らかなセキュリティリスクに加え、蓄積される技術的負債についても考える必要があります。認証情報を変更する場合は、すべての箇所で変更しなければなりません。その箇所を特定するには、時間と労力がかかります。そもそも時間に余裕があるなら、時間を捻出するために自動化を導入しようとはしないでしょう。

ですから、セキュリティの第1原則に反しないでください。より安全かつ賢明に対処しましょう。自動化は、規模とスピードの要件に対する場当たり的な対応であってはなりません。自動化は本来、戦略的な取り組みです。つまり、実装方法が長期的に及ぼす影響に、より注意を払う必要があります。

著者について

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。

Lori Mac Vittieのその他のブログ記事