BeyondTrust社Blog “Server Security Best Practices for Unix & Linux Systems” March 23, 2021 by Karl Lankford より
サーバのセキュリティ、そしてUnixおよびLinux環境の保護は、これまでにないほど緊急性を増しています。PaaS、IaaS、SaaSといったモデルの採用がここ数年にわたって進められていますが、リモートワークの爆発的な増加や多岐にわたるビジネスのやり方に応えるため、デジタルへの移行が加速している時代において、すべてをクラウドで行うことへの要求が非常に高まっているのです。このように急速に発展が進み、ますます複雑さが増している世界では、サーバの脆弱性や保護策における穴が大きくなり、攻撃を仕掛ける者－外部の脅威実行者あるいは内部者－がこれを悪用して甚大な被害を与えることになりかねません。このブログでは、以下のことを中心にUnix/Linuxサーバのセキュリティとは何かについて探ることにします。
- UnixとLinuxの共通のユースケース
- LinuxとUnixのサーバを守るための課題
- Unix/Linuxサーバセキュリティのためのオープンソースソリューションと自動ツールの長所と短所
- Linux Security Modulesとはどんなもので、どう使えばセキュリティを高めることができるのか
- Unix/Linuxセキュリティのためのエンタプライズクラスのソリューション
- UnixとLinuxの環境を強化し守るための10のベストプラクティス
- Unix/Linuxサーバを守るのに最も適したソリューション
なぜLinux & Unixのセキュリティ=(イコール)クラウドのセキュリティなのか
Linuxは、作業負荷のばらつきの大きなクラウド内で動作するオペレーティングシステムとして最も広く使われています。Linuxは、ウェブやデータベース、メールサーバアプリケーションだけでなく、ブロックチェーン、コンテナ、TV、IoT、SCADA、CI/CDパイプラインなどを実行するのにもよく使われています。インターネットと接しているクラウドアプリケーションの量が増えたため、増え続ける脅威の手から、このように価値の高いシステムを守ることは、これまでになく重要になっています。
分散型システムの性質として構成が安全ではない傾向があり、セキュリティ防御上の穴が生じやすくなっています。たとえば、ウェブアプリケーションで構成が単純なら、脅威の実行者は基本サーバからリモートでコマンドを実行することができます。目的を持った脅威の実行者はこのアクセス権を利用してシステムに常駐し、特権昇格を求め、ついにはシステム全体を支配することにもなるでしょう。そのうち、このような高度な持続型の脅威（APT）は、個々の頭痛の種というだけでなく、広範囲にわたる侵入の脅威に形を変え、世界中のデジタル社会を震撼させることになります。SolarWindsの攻撃で起きたことがまさにそれでしょう。
問題の範囲はUnixやLinuxの構成だけにとどまりません。システムやプラットフォームの数が増えるにつれ、インフラストラクチャの操作を行う人は急速に増え続ける特権ID（人間のものマシンのもの問わず）も管理しなければならないのです。IDがこれほど急激に増加していることで、組織は難しい状況に直面しています。不適切に保管されたSSH鍵が一つでもあれば、そこが攻撃ベクトルとなって組織が侵入を受けることになりかねません。ひと言で言えば、形勢は明らかにこちらに不利です。– 攻撃者の狙いとしては、成功の機会が０パーセント以外なら有利に比べ、セキュリティチームは常に100パーセントの保護を目指さなければならないのですから。
ではここで、LinuxとUnixのシステムが動作する環境をあらためて考えてみましょう。これらは、ほぼすべての階層で、基幹業務プロセスの要となるものです。こうしたシステムの中には継続的な処理を制御するものもあり、シャットダウンからの復旧には数週間を要することもあります。サイバー攻撃や構成不備のためにこうしたシステムが利用できなくなれば、その組織の評判にも経営にも甚大な影響が出るでしょう。
UnixとLinuxのセキュリティの課題とは何か？
成長を続ける最先端の技術に伴う課題はたくさんあります。サイバーセキュリティのチームはLinuxやUnixのシステムでのアカウント、とりわけrootのような高い特権を持つアカウントを能動的に管理しなければなりません。これが課題の始まりです。システムにはそれぞれ、固有のローカルユーザの保管庫があります。これはごく狭い環境であればうまくいくのですが、会社が成長して多くのシステムを構築するようになると、特権アカウントの数も倍増し始めます。
こうしたアカウントを管理しやすい立場にいるためには、次のような問いへの答えを考えることが重要です。
- システム管理者はどのようにすべてのrootパスワードを保管しているか？
- パスワードが平文でどこかに書き留められていたり保管されたりしているか？
- ITセキュリティ担当者はどのようにして、こうしたパスワードが脆弱でないと確かめられるか？
- ITセキュリティ担当者はどのようにして、デフォルトのパスワードが変更されたことを確かめられるか？
- システム管理者はどのようにして、システムファイルの統合性を確かめられるか？
- システム管理者はどのようにして、アプリケーションのセキュリティを確保しているか？また、どのようにしてSSH鍵を保護しているか？
サーバ全体で特権IDとアクセスを管理するには：5つの「W」
どのような環境においても、こうした特権IDを管理する際には、属している組織に合ったセキュリティ手段やプロセスを実現するために念頭におくべき5つのWがあります。
1. Who（誰）
LinuxまたはUnixのユーザのIDは誰のものか？
誰がアクセス権を持つべきか？
2. What（何）
対象となる資産は何か？
接続方法は何か？
3. Why（なぜ）
LinuxまたはUnixのユーザは、なぜこのシステムへのアクセスを必要としているか？
なぜこの動作を行う必要があるのか？
4. When（いつ）
この変更はいつ行うべきか？
会社がこの変更を認めるのはいつか？
5. Where（どこ）
どこからこの変更を実行するか？
この変更の完全な監査証跡はどこにあるか？
サーバの特権を管理するためのオープンソースソリューション
上の項で挙げた問いに答え、課題を解決するために、Unix/Linuxのプラットフォームには多くのオープンソースソリューションがあらかじめインストールされています。たとえばsudoは、標準ユーザがスーパーユーザ（root）または指定された他のユーザとしてコマンドを実行できるように、ほとんどの分散ファイルに入っている無償のアプリケーションです。Windowsの右クリックの「runas」オプションのようなものといえます。これはわかりやすい最小特権の原則（PoLP）を適用し、ユーザが自由に特権を昇格できるようにするためのものです。しかし、この簡単な解決法は、拡張が著しいインフラストラクチャは言うまでもなく、昨今のコンピュータ業界の様々な需要に対しては適切とはいえません。sudoの大きな脆弱性が最近Qualysの調査チームによって発見されたことを心に留めておくべきでしょう。この脆弱性は2011年からあったもので、最近になってやっと世間に注目されるようになったのです。詳細はこのブログでお読みいただけます。
システムの数が増えるにつれ、sudoの管理は難しくなります。sudoのせいであらゆるホストを個別に管理しなければならず、これは管理者にとっては複雑で時間がかかる作業で、最終的には手に負えなくなります。一元管理できないというこの特徴のためにほころびが生じ、ひいてはこれがリスクにつながります（この拡張性の問題に対処しようとした無償の自動化ツールもあり、これについては後述します）。
拡張性がないことに加え、sudoは特権の問題への対応やroot IDの管理も完全にはできません。その結果、チームのメンバーはrootや他のアカウントを共有することになり、それが回避策や侵入を許すことにつながるのです。
rootアカウントを共有すると、監査またはコンプライアンスの問題が生じます。– どのような特権を伴う動作についても、消せない監査証跡を証明することがまったくできなくなってしまうのです。sudoの動作ログは 改ざん防止策が施されていないので、コンプライアンスを証明したり、不正の問題を有効に調査したりすることができなくなります。
sudoのこの問題点で窮地に陥るのを避けるため、またはこれを回避するための最善かつ最もうまくいく方法は、真の最小特権を用いたサーバ管理ソリューションに移行することです。これによって組織は、固定された特権がなくても、またアカウントを共有しなくても、すべてのユーザを実行させることができます。操作者と管理者はいつも使っているアプリケーションを引き続き実行することができますが、昇格は、業務ポリシに基づいて個々のコマンドに対してのみ行われます。ユーザの観点から見れば、これは動作コマンドの昇格をスワップアウトするのと同じくらい単純なことです。その後、すべてのイベントは信頼性を確保するために完全に記録され、詳細なポリシのおかげでどのような動作が可能か制御することができます。特権を伴う動作の情報はすべて改ざん防止の監査証跡に記録され、監査者やインシデントレスポンスのチームが使えるようになります。
下の図でわかるように、既存のワークフローへの影響は最小限に抑えられます。
スクリーンショット1: 標準ユーザがジャストインタイムでpbrunでrootに昇格し、Dockerコンテナを開始
スクリーンショット2: BeyondTrustソリューションから過去のセッションをリプレイしている例。ここではユーザがpbrun bashで昇格し、「apt upgrade 」コマンドをジャストインタイム昇格のために実行している。
Linux Security Modules（LSM）がどう機能するかを理解する
LSM、すなわちLinux Security Moduleは、Linuxカーネルと共に出荷されます。LSMはLinuxカーネル内に加わったセキュリティのフレームワークで、従来の任意アクセス制御（DAC）ではなく強制アクセス制御（MAC）をシステム全体に行うものです。LSM は、ユーザのシステムコールで内部の重要なカーネルオブジェクトがリクエストされた場合に、カーネルのあらゆる場所にフックを挿入します。そうすると、このフレームワークのおかげで強制アクセス制御を基盤としたセキュリティモデルを違った形で実装することができるのです。
LinuxカーネルにはいくつかLSMモジュールが組み込まれていて、それぞれの手法と管理形態は少しずつ異なっていますが、すべて等しくシステムの安全性を向上させるでしょう。具体的な例としてSELinuxを取り上げてみると、このソリューションでは、従来ある「読み込み」「書き込み」「実行」というデフォルトの許可と、ファイルやディレクトリへの許可の割り当てを超えたきめ細かいセキュリティポリシを実施します。
LSMが特に強力なのは、すべてのシステムコールがポリシデータベースでチェックされ、デフォルトで拒絶されるようになっているところです。これは、コンテクストをファイルやネットワークのポート（たとえば）に適用したり、こうしたオブジェクトにラベルをつけたりすることによって実現します。ポリシはその後、こうしたマッピングを参照して1つのまとまったポリシとなります。
幸いなことに、管理者は白紙の状態で規則やラベルを書く必要がありません。今は見本となる規則が数多くあり、システムへの導入や試験も簡単になっています。
なぜLinux Security Moduleを使うのか？
Linux Security Moduleは、途中で攻撃者を阻むことが証明されています。
たとえば、ApacheのLinuxサーバ上で動作する脆弱なPHＰサイトがあるとします。LSMが正しく導入されていれば、PHPの脆弱性が大きくなってマシンに及んでも自動的にブロックされます。
攻撃者が脆弱性を介して指揮・統制を行える場合は、昇格したり横方向へ移動したりしようとします。sudoerやpasswd、known_hosts、resolve.confなど重要なファイルはすべて、その攻撃者が存在しているPHPセキュリティポリシに対し異なるラベルを関連づけます。PHPポリシは他のオブジェクトには読み込みや書き込み、実行などの権利を許可しません。
このような攻撃は興味深く、そして危険でもあります。というのは、サーバにパッチを当て、完全に更新し、安全に管理することはできますが、それでも攻撃者は別の脆弱性を介してアクセスしてくることが可能だからです。LSMはここで重要なセキュリティ手段になってくれますが、鎖の強さは最も弱い環によって決まるのです。
- このようなrootアカウントを管理して特権昇格を阻止することについてはどうか？
- ITセキュリティの担当者はシステム動作とセッションデータの「よい」基準を知っているか？
- ITセキュリティの担当者は、５つのWの監査証跡を把握しているか？
これがLSMの限界であり、別のセキュリティ手段が必要となる理由です。
BeyondTrustのPrivileged Management for Unix and Linux製品（当社のEndpoint Privilege Managementソリューションの一環で、Privilege Management for Windows & Mac製品もこれに含まれている）は、エンドポイントでの動作の基準や中央での監査証跡を作成することができます。システム管理者はすべて標準ユーザとしてシステムにサインオンし、ジョブを遂行するために必要なツールやアプリケーションを昇格させるだけです。またBeyondTrust Password Safeは特権アカウント（人間、アプリケーション、マシンなど）を自動的にスキャンし、登録し、管理します。 組み込まれているrootアカウントのみならず、既知の、または発見された特権ユーザの身元情報やSSH鍵もです。このようなアカウントを管理下に置くことによって、Password Safeはすべての資格情報をちょうどいいタイミングで発行し、使用後に変更されるようにするのです。
自動化ツール－コードとしてのインフラストラクチャ
自動化ツール、具体的にはコードとしてのインフラストラクチャ（IaC）は、大規模環境の構成管理をじつに簡略化しています。かつてはうんざりするほど長時間にわたり大変だった作業（構成ファイルを100台のサーバで変更したり、ファイルをそこにコピーしたりすることなど）が、今では多くのプラットフォームやオペレーティングシステムを通じて、1つのツールで達成することが可能なのです。
チームはこの技術を応用して、システムでのアカウント管理を単純にすることができます。中央にある親ノードから、新しいユーザやグループ、ホームディレクトリなどを作成したり定義したりすることもできます。しかし、SSSDのようなこうした組み込み式のソリューションは、複雑な環境ではうまく働かず、グループポリシや多因子認証（MFA）、一元レポーティングといった高度な機能がありません。こうしたツールはまた、別のリスクを引き込む恐れもあります。たとえば、認証ツールを強化する高度な特権アカウントは固定化されていることが多く、永続的な特権の数も膨大です。この種のアカウントは組織のインフラストラクチャ全体の統制が可能であるため、ほぼ間違いなく、どのようなサイバー攻撃においても意図を持った脅威実行者の格好の標的となります。
またこれがあっても、一元ID管理が必要であることに変わりはありません。一元ID管理がなければ、あらゆるシステム管理者は、それぞれ固有のパスワードとポリシを持つアカウントが2つ以上必要になります。これもBeyondTrustのEndpoint Privilege Managementソリューションの一部であるActive Directory (AD) Bridgeのようなツールを使えば、システム管理者はすべてのユーザIDをActive Directoryで統合することができます。すべてのユーザIDと認証をADで一元管理することで、企業は信頼できる情報源を一つだけにすること、すべてのシステムの管理場所を一つだけにすることができ、しかもWindowsのエンドポイントに限定されません。BeyondTrustのAD Bridgeがあれば、すべての構成やロールアウトや更新を中央のウェブアプリケーションで実施することができます。このプラットフォームのおかげで、身元認証チームの作業はずいぶん楽になります。参入者、移動者、退出者などの処理を行う時間が減らせるうえ、監査とコンプライアンスのための承認レポートを作成する労力も減らせるからです。AD Bridge の利用によってITオペレーションの時間が大幅に削減できるだけでなく、セキュリティチームも単一パスワードの方針を徹底させながら、シングルサインオンを使うことでシステムのユーザがこれを簡単に行えるようにできます。
UnixとLinuxに関するセキュリティ強化対策のベストプラクティスのトップ10
システム管理者がUnixとLinuxの環境でセキュリティを強化するために講じるべき10の措置を下記に述べます。
- 業務アプリケーションの実行には堅牢で安全で評判の高いオペレーティングシステムを選ぶ
- 物理的なセキュリティを高めるため、ハードディスクを丸ごと暗号化して、使っていないときもファイルの安全性を確保する
- 組み込み型のLinux Security Moduleとファイアウォールを利用して、ローカルのセキュリティを高める
- できる限りパッチで最新の状態にしておき、この手順を自動化して、脆弱性を残さないようにする
- 共有アカウントを排除する－1人について1つのユーザ名、ID、パスワード、ホームディレクトリを持つ１つのアカウントを強制実施する
- リモートのSIEMや監視ソリューションにすべてのシスログイベントを送る
- 自動の発見と登録の機能を使ってすべての特権を持つアカウントパスワード、鍵、秘密を管理し、環境の変更をサポートする
- ポリシを定義し強制実施することにより、すべてのユーザに対して最小特権を実装する
- 完全な監査証跡のため、すべての特権セッション動作をログ・記録する
- ファイル統合監視（FIM）を使い、重要なファイルが改ざんされないようにする
BeyondTrust による軍事レベルのLinux & Unixセキュリティ
特権アクセス管理（PAM）ベンダーを選ぶ際、PAMの全体を見ているか、また拡張だけでなくプラットフォームを選ばず、導入がしやすく、ROIが数値でわかるような堅牢なセキュリティ機能を持っているかどうかということを確認するのが重要です。
BeyondTrustが役に立つUnix/Linuxの特権管理についての主なコンセプトを以下に述べます。
- パスワードポリシが守られ、固定化して脆弱にならないように、*nix環境の中でアカウントやパスワードや鍵を管理する。これによって、パスワードの再利用やパスワード解析、パス・ザ・ハッシュなどさまざまな種類のパスワード攻撃を防ぐことができる
- 最小特権の原則を導入し、過剰な管理者特権を排除する。これは、UnixとLinuxの特権上昇攻撃と共に横方向への移動を防ぐことにも役立つ
- 共有アカウントの危険な使用をなくし、否認不可性を実現する
- *nix環境へのアクセスを制御し、承認された場所からの承認と認証を受けた個人に対してのみセッションを許可する
- コマンドラインのフィルタリングを行い、不安定な悪意のあるコマンドを阻止する
- ユーザの動作をログし、組織全体のコンプライアンスを徹底する
- 問題、変更、インシデントについての監査証跡を完全にするため、リモートで特権を伴う動作を管理・記録しておく。BeyondTrustでは、すべてのセッション動作の完璧な監査証跡が残せる
- 構成を調整したり進行中の疑わしいセッションを中断または終了させたりするなど、セキュリティにおいて先手の措置がとれるように、普段と違う動作に対して警告や通知を受けられるようにする
- 一元化され、統一された管理を行って、IT担当者が可能な限り効率よく安全に作業できるようにする
BeyondTrustは30年以上に渡って、サーバの特権管理や完璧なPAMプラットフォームをサポートしてきました。BeyondTrustなら、ご自身の環境に合ったペースで、IT資産全体を通じた特権アクセスのセキュリティ制御を充実させることができます。
以下に、UnixとLinuxのセキュリティ分野で鍵となるBeyondTrustの4つのソリューションを挙げます。心に留めていただきたいのは、PAMの手順では特に始める順序を決める必要がなく、BeyondTrustがお客様の現在の状態に鑑みて、次にとるべき手順をきちんとお勧めできるということです。また、当社のソリューションは１つのプラットフォームに統合し、結合させて他の機能を活用することができます。
- Privilege management for Unix/Linuxは、Unix、Linux、ネットワークシステムで真の意味での最小特権を実現するためのもの。rootアクセスを制御し、ユーザの動作を監査し、セッション監視とリプレイ機能を使うことができる
- Active Directory Bridge(旧称PBIS)は、Microsoft Active Directoryの認証をUnixとLinuxのシステムに拡張し、シングルサインオンとグループポリシの構成を行うためのもの。
- DevOps Secrets Safeは、CI/CDのツールチェーンで使われている秘密を一元的に保護し、管理するためのもの
- Password Safeは、rootアカウントやSSH鍵、ローカル管理者など、あらゆる種類の特権アカウントを発見し、監査し、監視するためのもの
データシート：Unix & Linux向けの特権管理
白書：錯綜したUnix/Linuxのセキュリティを簡略化する
Karl Lankford、BeyondTrust社 Director, Solutions Engineering
Karl LankfordはBeyondTrustのソリューションエンジニアリング部長で、同社で働き始めてから4年になる。10年間さまざまな業界の企業と仕事をしたことで、セキュリティに関して幅広い経験と知識を身につけ、業界の会合では常に発表を行う立場にある。