調査報告:DevOpsサーバのインフラセキュリティの必要性

avatar

 2018.09.04  Japanブログ編集部

DevOpsの利用では、デリバリー・パイプラインのそれぞれの段階で複数のツールが適用されていきます。IntSightの新しい調査報告では、インターネット上の攻撃にさらされる可能性のあるこれらのツールに焦点を当てています。

新しいツールが処理に加えられる毎に攻撃対象範囲は広がり、そして多くの場合、新規の開発・デリバリツールは、セキュリティチームの監視下に置かれることなく使用されています。 DevOpsのそれぞれのステップで複雑なツールが使用されると、潜在的な攻撃経路と不正アクセスのリスクは急激に増加します。

IntSights社の調査では、DevOpsツールの大半がウェブベースだとの想定の上でインターネット経由でアクセスが可能なDevOpsサーバとソフトウェアを対象に行われました。

この調査は、例えば「jenkins.example.com」というホスト名でJenkinsオートメーションサービスを検索するように、既知のDevOpsツール名と異なる組織のドメインを組み合わせてコンパイルされた26,000近くのURLとサブドメインのリストを中心にして行われました。

ライブで有効なレスポンスをするすべてのサーバをオープンサーバとみなした上で、どのようなセキュリティがあるのかを判断するさらなる調査が行われました。「派手な攻撃ツール」ではなく、OSINT(オープンソースインテリジェンス)ツールとウェブサイトだけが使用されました。

 

DevOpsツールは攻撃対象範囲を拡大するのか?

テストされたURLのうち23.6%(25,876件中5,967件)が、ウェブを通じてのアクセスが様々なアクセスレベルにおいて可能であるという結果が出ました。ユーザ名とパスワードの組み合わせもなく完全にソフトウェアが公開されていたケースもありました。

一つ例をあげると、Jenkinsのサーバは調査用の複数のビルドを用いてアクセスすることが出来ました。自動ビルドツールはしばしば認証情報をハードコードしたり、誤ってコマンド経由でデータを暴露したり、ログファイルで出力したりと、さらなる攻撃のきっかけを与えてしまいます。

また別の例では、デフォルトでは認証を要求しないオープンな Elasticsearchのサーバが見つかりました。  Elasticsearchは分散型の検索・分析エンジンで、ログやセキュリティデータといった豊富な情報が含まれていることが多いのです。別の言い方をすれば、攻撃者にとっては宝の山のようなものです。

他にも認証セキュリティが存在しているものの、アプリケーションに委ねられているケースもありました。またデフォルトでログインできたりパスワードポリシーが弱いとDevOpsツール用のパスワードも簡単に推測されてしまうことになりかねません。

この結果はそれほど驚くに値しませんが、ツールチェーンとインフラを守ることの重要性を思い起こさせてくれます。

私たちは自動化されたセキュリティをプロセス内に適用してデリバリ中のものを確実に守ることに意識を集中しがちですが、ツールとツールを実行しているサーバにも検査と監視が必要なのです。

 

DevOpsツールが危険に曝されるのを防ぐ方法

DevOpsツールが曝されないための一般的な対策としては以下のとおりです。まず始めに、この調査報告の前提とも関連しますが、「隠しておくこと」が最善策です。DevOpsのツール名やその他の明白な識別子は、インターネットに接続するサーバー名では使用しないことです。

この手掛かりがなければ、この調査自体がうまく行かなかったでしょう。デフォルトではないポートの使用は役に立ちますが、外部からのアクセスをブロックしたり、DevOpsツールにアクセスするためのVPNを要求すれば、攻撃対象範囲を最小限に抑えるでしょう。

私たちはいつも多要素認証を称賛していますが、ツール上で多要素認証が使用できるようになればパスワードの脆弱性を補強できます。

DevOpsツールとインフラの保護に関しては、従来のセキュリティツールが大きな役割を果たしています。Tripwire Enterpriseには、DockerとKubernetesといったツール向けのDevOps用ポリシーも組み込まれているので、これらのツールの設定で最高水準のセキュリティ基準を確実に満たしていることになります。

ファイルと構成の変更を継続的に監視することで、セキュリティ体制を維持し、データ侵害が発生した場合には、早期に通知することができます。Tripwire IP360などのツールを使って脆弱性とネットワークのスキャニングを行えば、脆弱性やパッチの欠落の検出はもちろん、どのシステムやサービスへのアクセスが可能かという現状を把握出来るようになります。

ビルドツールや継続的な統合ツール、テスティングスイート、セキュリティツールなどを新しいDevOpsメカニズムに追加するならば、それに伴うリスクを軽減するためにツールとインフラを護ることが重要になってきます。

SANS:基本への回帰

RECOMMEND関連記事


この記事が気に入ったらいいねしよう!