台本に忠実に、子供たち：職場でのすべきこと、すべきでないこと

スクリプトは、物事を迅速かつ自動的に実行したい経験豊富な管理者にとって、今や第一選択肢となっています。しかし、スクリプトには独自の問題が伴います。

ここやここを見れば、その痛みが分かります。ソフトウェア定義データセンターは純粋にコード内（もちろんその下にはハードウェアがあります）に存在するため、事故を防ぐためには、コードも効果的に管理・制御される必要があります。

スクリプトはオペレーターの要求を数百倍、数千倍も高速に実装します。効率性、予測可能性、そして（通常は）スピードが向上します。

しかし、スクリプトが適切に制御されていない場合、事故は1万倍も早く発生する可能性があります。さらに、スクリプトの対象となる大規模な環境の場合、問題はデータセンター全体またはアベイラビリティゾーン全体に影響を及ぼす可能性があります。Webスケールでは、1時間あたり数十万のダウンタイムコストが発生することも珍しくありません。

何を制御するか

スクリプトが諸刃の剣である理由は容易に理解できます。効率性とスクリプトの重要な側面の制御の間には、バランスが求められます。

• 誰が運営しているのですか？
• スクリプトのバージョンは管理されていますか?
• スクリプトは実装が承認されていますか?

管理者として、ちょっとしたスクリプトを作ってデータを収集し、CSVシートに書き出す方がどれだけ簡単かは分かっています。しかし、環境に書き込むスクリプトはどうでしょうか。些細なエラーが積み重なり、生産性はお預けです。スクリプトの愚かなデフォルト設定のせいで、Active Directoryインフラ全体が壊滅状態に陥った例を何度も見てきました。

誤解しないでください。これはAWS、Azure、Googleなど、あらゆるクラウドプロバイダーに共通する問題です。人間の過ちが原因であり、自動化によって（ほとんどの場合）さらに悪化しています。

このリスクを管理するには柔軟性とバランスが求められますが、一部の組織で私が目にした対応は極めて強引で、スクリプトツールを削除するというものでした。潜在的なリスクを理由に、ツールを厳しく制限している企業も見てきました。しかし、このアプローチの現実は、誰もが便利だと知っているアドホックスクリプトなしでは、管理者の業務が困難になるということです。確かにスクリプトは危険な場合もありますが、多くの問題は軽減可能です。

より良いアプローチは、インテリジェントなデフォルトをいくつか設定し、コンピューティング プロセスをより適切に管理することです。どちらも、不正なスクリプト コードが発生する可能性と影響を大幅に軽減できます。

早速ですが、ベストプラクティスは明らかです。アドホックスクリプトを、夜間に実行される重要なスクリプトから分離することです。どのアカウントが何を実行したかを把握しておくことは重要です。これらのスクリプトはすべて、以下の点に注意する必要があります。

• 適切に文書化されたサービスアカウントと強力なパスワードを使用し、必要最小限の権限で実行してください。情報を収集するだけのスクリプトには読み取り専用権限以外は何も必要ありません。ですから、これ以上の権限を付与する必要はありません。読み取り専用権限では変更を加えることができないため、複数の権限を混在させて実行するよりも安全です。また、監査担当者が訪問してきた際にも、監査が容易になります。これを怠ると、監査で大きな負担がかかります。
• 他のほとんどの言語は、現在のユーザーコンテキストで実行されます。それ以上のことはできません。PowerShell/Ruby/BASHでできることは、他のアプリケーションでもできます。任意のアプリケーションが勝手に何かを実行しないようにすることも同様に重要です。技術者にはそれぞれお気に入りのツールがありますが、残念ながらリストにない場合は仕方ありません。このせいでマシンが消去され、イメージが再作成されるのを見たことがあります。やりすぎでしょうか？確かに。しかし、企業はツールを迅速かつ容易に導入できる方法も提供する必要があります。そうしないと、パフォーマンスが低下します。
• 技術的なことにはこだわるから、スクリプトを管理者として実行してはいけない。言うまでもないだろう。完全なドメイン管理者権限でスクリプトを実行すると、問題が発生するだけだ。
• スクリプティングホストはリスクの抑制に役立ちます。デスクトップからスクリプトを実行できるのは非常に便利ですが、監査の観点からは悪夢です。環境内の無作為なラップトップ、デスクトップ、サーバーから何百ものスクリプトが実行されるからです。スクリプトの実行を少数のスクリプティングホストに制限することで、監査と管理が容易になります。
• スクリプトは安全な場所に保管し、厳重に管理する必要があります。バージョン管理は特に重要です。スクリプトが変更されたり、動作しなくなったり、あるいはさらに悪いことに、エラーを遡って修正したりする場合、バージョン管理は特に重要です。また、管理者がスクリプトを改変するのを阻止する効果もあります（この点では、スクリプトに署名を付けることが効果的です）。
• 多くの最新のスクリプト言語には、トランスクリプト機能が組み込まれています。これらの機能は、実行されたスクリプトを正確にログ（ログサーバーなど）に記録するのに役立ちます。管理者が実行中のスクリプトが全てログに記録されていることを認識していれば、実行内容を再確認し、より慎重に行動するようになるはずです。

GitHubのようなサービスに付属する、管理者レベルの「ダウンロードして実行するだけ」の機能にも、他の危険性が潜んでいます。管理者がスクリプトの機能を十分に理解していなかったために、このようなスクリプトが問題を引き起こした例を目にしたことがあります。アクセスをブロックまたは制限することは、まず良い対策です。GitHubは確かに便利ですが、たった1つの悪質なスクリプトで大きな被害をもたらす可能性があります。

繰り返しますが、スクリプト自体が必ずしも悪いというわけではありませんが、環境には管理と制御が必要です。不評かもしれませんが、GitHubなどのサイトへのアクセスを制限するのが解決策になるかもしれません。確かに技術者たちは激怒するでしょうが、和解の糸口は提示できるはずです。

私が実際に効果があったと見てきたのは、スクリプトツールバンクを構築することです。これらは成熟し、社内でピアレビューされています。時間はかかりますが、多くのアドホックスクリプトが同じ機能を果たしており、管理者によるいわゆる「車輪の再発明」を防いでいます。

さらに、より高度なスクリプト言語の監査機能について誤解したり、知らない人もいます。例えばPowerShellを見てみると、最新リリース（バージョン5）には新しい機能が追加され、ログ機能が組み込まれており、SIEM（セキュリティ情報イベント管理）システムに転送可能な情報メッセージを作成できます。

最大のリスクの一つは、スクリプトを実行する人々です。集中管理されたスクリプトリポジトリは必須です。スクリプトの実行を阻止することは難しいかもしれませんが、許可されていないスクリプトの使用とその影響を軽減するのに役立ちます。悪意が原因となることは稀です。結局のところ、機能性と使いやすさと、セキュリティおよび管理者の能力のバランスを取ることが重要です。®