運用体制で「もう少し気にしたほうがいい」と思うこと
川口洋氏（以下、川口）：（スライドを示して）3つ目のテーマは、運用管理体制のチェックで必要だと思うことです。これは開発よりも運用まわりです。このあたりは「みなさんもう少し気にしたほうがもっと安全なのではないか」という事例を聞いておきたいと思います。開発時にきちんと作っていても、例えばベタですが、システムのパスワード.xlsxというのがあって、パスワード管理台帳が見えることはけっこうあると思います。
私もいろいろな相談を受けている中で、実はパスワード台帳を持って行かれて「さんざんシステムをペンテスターにやられました」という事例もあるのですが、ルスランさん、そのあたりはどうですか？
ルスラン・サイフィエフ氏（以下、ルスラン）：めちゃくちゃあります。特にオンプレドメインがある場合は基本的にファイルサーバーもあるので、「平文パスワードの管理」、「共通パスワードの管理」と「脆弱なパスワード」の3つが、だいたいどの報告書の中でもトップ1位、2位、3位になっています。
最近はクラウドのみの環境になり、みなさんがパスワードマネージャーをきちんと使うようになってきて、多少はなくなってきました。でも大企業やオンプレのある環境や、すごく昔からある会社であれば整理が大変で、昔ながらのやり方で残したりするものがたくさんあります。
川口：ここまでがんばってやっているのに、「なぜパスワードリストやパスワードが書いてある手順書がさらりと置いてあるんだ」みたいな感じの相談を受けると、「あぁ、ここがもうちょっとなんとかなればもうちょっと安全なのにな」というところで。「見つけたのがセキュリティ診断をしてくれるセキュリティベンダーでよかったね」という感じもします。
ルスラン：そうですね。平文パスワードがないにしても、基本的には我々がゴールとするシステムや、仮にそれを何かしら特殊に作られたシステムにしても、そのシステムのパスワードが毎日変わるわけではないし、基本的には作られてずっと運用されることになります。
だいたいどの会社でも、納品物フォルダがあります。いろいろな会社が作ってくれた納品物の仕様書があって、その中にパスワードが書いてあるようなところでは、だいたい半分以上のパスワードが取れる感じです。
川口：あるあるですが、納品物フォルダは本当にゾッとします。
ルスラン：もらってから変えていればいいのですが。
川口：そうですね。
ルスラン：でもそのままなので。隣に「変えちゃだめ」と書いてあったりします。
APIキーなどの鍵の管理を安全に行うのは難しい
川口：パスワードはまぁそうだなと想像はつくのですが、APIキーなどの鍵の管理をどう安全に運用していくかは、けっこう難しいです。まだまだ鍵を使わないケースもあって。今日は、「せいぜいSSH（Secure Shell）の公開鍵ぐらい」という組織もあれば、いわゆるAPIの鍵をバンバン使いこなす企業の両方が聞いているのかなと思いますが、鍵管理の運用はどうですか？
ルスラン：そうですね。SSHに関していうと、そもそもSSHで鍵で認証するのであれば、もうかなりいいという感じです（笑）。
川口：まだマシということですね。
ルスラン：まだマシですね。それにYubiKeyで二段階認証があれば「おー、すごい」となります。そうなると、基本的にそのサーバーは対処しなくていいのですが、ゴールを達成するには絶対にその経路を通る必要はないので、他のSaaSに決めます。パスワードのかかっているSSHの認証、証明書だったらそれをちょっと解析して見てみます。
あとは、個人というか社員のアカウントであれば、社員のアカウントとパスワードが同じだったりするので、それで入ったりすることはあります。私が入社したばかりの時、牧田さんと一緒にやった案件で、ある鍵ですべてのサーバーに入れたところもありました。
川口：鍵が全部同じだったと。
ルスラン：はい。
牧田誠氏（以下、牧田）：例えばメンテナンス用として、監視用や障害対応用（の鍵）は作りがちです。それは各企業で作っていると思いますが、それが仮に攻撃者に取られてしまうと、やはり悪用されます。
ルスラン：そうですね。他のAPI鍵やAWS鍵となってくると、やはり今でも外部と内部という感じがかなりあるので。例えば、ある会社は内部のほうはある意味でセキュアなこともあります。その中には内部のGitがあって、その内部のGitはそもそも認証なしでエクスプローラーですべてのプロジェクトが見られて、そのプロジェクトが内部だから、鍵がそのままハードコードされている感じになっているものもあります。
そこから始まる話としては、アクセス制限をしていない会社がかなり多いです。要は、開発者であっても「その開発者がアクセスできる領域はどこまでか」を決めていかなければいけないのですが、基本的に何でもかんでもできたりします。
あとは、一般社員で営業なのに認証なしでGitに入れて、プロジェクトをクローンしたり、Dockerのイメージを取ることができたりして。そこからいろいろ鍵を取って、本番環境まで至ってしまうこともあります。
ある会社は（鍵の保管場所を）物理的にセキュアエリアやセキュアルームみたいな感じで作っているのですが、そうなってくると、論理的にはそのネットワークに入れてしまう。そこはある程度信頼度の高いエリアということで、二段階認証も何もないことになってしまうことはあります。
オンプレだからと横展開をしてしまうと、気付かなければずっとそこにいて何でもできる状態にもなるし、その上にやらなければならない二段階認証で入らないといけないお客さんになると、「かなりできているんですね」と喜びます（笑）。
川口：「しっかりやっているな」と。
牧田：せっかくセキュリティルーム、物理的に行かないとDBに触れないみたいな制限を作ったとしても、運用を考えると、障害が発生してしまった時は、やはりどうしても自宅から緊急対応をしたいじゃないですか。それこそセキュリティパッチを緊急で当てたいとか。そうすると、物理的にそこの場所に行く、データセンターに行くのは難しいので、みなさんどうしても遠隔でアクセスしたくなるんですよね。
そのメンテナンスの手順書を作りがちで、パスワードや鍵をきちんと丁寧に書きがちです。そうすると、せっかく物理ルームでアクセス制限をしているのに、緊急メンテナンス用・障害対応用のVPNの情報を見られることになります。アクセスできる場合が多いので、それを使ってその場所に行かなくても入れてしまうことがあります。
ルスラン：そうですね。なので、緊急用の手順書や鍵が置いてあるところは、例えば仮にファイルサーバーとして考えても、そのファイルサーバー自体が信頼のあるユーザーしかアクセスしないと考えられているかもしれません。
でも、攻撃者はある権限までは入れてしまうし、確かに物理的に行かないとそこのDockerには行けませんが、手元に緊急用のVPNの認証情報もあって。もちろんつなげられるかどうか、つなげられる時間が決めてあるかどうか、あとはつながった途端に監視されて切断されるなど、会社によってはいろいろなプロセスがあるはずですが、攻撃者もそれを使い回してつなげればいいので、一番終わるシナリオとしては、何も気付かれず、誰も何も監視をせずにそこに入って終わってしまうテストもあります。
管理者におすすめなのは資産管理
川口：そんなやばいやつを動かすのだったら、Slackに一報を飛ばしてほしいぐらいですね。
ルスラン：そうですね。
牧田：それが監視なんですね。
川口：確かに。その中で1回突破しちゃったら、「最後にここを突破されたらまずい」みたいなところは通知が飛ぶ仕組みになっていないと気付きようがないですね。
ルスラン：そうですね。通知はすごくいいと思います。特に管理者側におすすめなのは資産管理です。どこに何があるかや、そのシステム自体にはどのように入れるかを把握しておくことです。
あとは、例えば彼らが自分で考えて作った経路があると思います。我々も中に入ってConfluenceを読んで、「なるほど。これが正常の入る経路」ということを把握します。イコール、その経路を通ると検知されてしまうので、そこを通ってはいけません。
川口：なるほど。
ルスラン：同じサーバーで同じシステムには他に入る経路があるのか。そもそも管理者自体がどうそこに入ってメンテナンスをやるかを考えてみる。（管理者が）利用してしまうと、実は検知やアラートを出す仕組みをわざわざ入れていなかったり、忘れたりしてしまって、（攻撃者が）最終的なところまで入れてしまうこともあります。検知を回避するという意味では。
ハニーポット的な施策はおすすめ
川口：大事ですね。ちなみにある役所で相談を受けていた時に「わかりやすいところにパスワードを置いてありますから」と、役所の人たちが言っていました。「なんでですか？」と聞いたら「悪い人が先にこれを使うと思うので、それを使ってもらって先にアラートを上げたいと思います」ということでした。
ルスラン：確かに。
牧田：賢い。
川口：「このバッチファイルは何ですか」と1回聞いたことがあります。「これは大丈夫なんですかね」「それはログインしたらまずいやつです。わかりやすく置いてあるので使われることを期待しているんですけど、使うやつがいたら速攻で取り締まります」みたいな感じのことを言われていました。
ルスラン：それはハニーポット的にとてもいいと思います。
川口：なるほどね。「わかりやすく置いておけば使われる」という感じはありだと思いました。これはログインをすると全社員や職員にアラートが飛ぶんだろうと思いましたが、そういう話もありました。その1個は（仕組みとしても）それほど手間がかからずに済みそうだからいいなと思いました。
ルスラン：でもその次のステップを考えないといけなくて、どこからそれがやられたかや、自分が次に何をやっていくかはステップの練習です。
川口：練習ね。
ルスラン：IR的な。要はその端末をネットワークから取り出さなければいけません。時間としてはどれくらいそれがかかるかとか。ユーザーが高権限のアカウントをハニーポットにしてある場合は、その高権限のアカウントで実はもう横展開されてしまった可能性もあります。それは、どう実装したかということになります。
川口：確かに。次々に出てきますね。
牧田：アクティブディレクトリの問題があります。あれはやはり非常に守りにくい。たぶんルスランさんは侵入できなかったことはないと思うのですが、この間印象に残っているフレーズで、「侵入できそう？ 大丈夫？」と聞くと、「アクティブディレクトリ、ドメインコントローラーでの侵入方法は無限にあるから大丈夫だ」と。
（一同笑）
牧田：そこをどう守ったらいいのというところで、例えばAdministratorというダミーのアカウントを作っておいて、それが使われたら取り締まるアイデアはいいかなと思います。
ルスラン：でもどのアカウントでも作っていいわけではないんです。ある会社がダミーアカウントを作ったのですが、どう見てもそのアカウントを使いたい気持ちにはなりませんでした。なぜかというと、権限もログインした経歴も何もなかったからです。パスワードが弱いかもしれないのですが、そのアカウントが取れたところで、何も変わらないというのは攻撃者としてはあります。
そもそも〇〇minというアカウントだったのですが、どうみても権限がなさすぎて逆に怪しいということが攻撃者からは見れるんですね。だから生きているようなアカウントで、多少権限があって歴史があるようなものを作らないと、高度な攻撃者であればすり抜けます。
川口：「こいつはあらっぽいぞ、臭うぞ」と。
ルスラン：そうです。
川口：そこまで見ると、ちょっと難易度が高い話ですね。ルスランさんはそこに落とし穴を掘っていても避けるんだなという感じです。
（次回に続く）
