.png){kind=small}
Vol.01 ゼロから始めるサーバーセキュリティの入門
- mitsuruto32
- 4月24日
- 読了時間: 15分
更新日：5月4日
この記事であなたがやるべきこと
サーバーセキュリティの基礎としてOS、ミドルウェア、ネットワーク、認証/認可、ログと監査の5項目でやるべきことを押さえておくこと
やるべきことに加え、考え方や思想を含めて理解し、他の分野においても応用できるようになること
はじめに
インフラエンジニアの皆さん、サーバーセキュリティには詳しいですか？ひとくちにサーバーセキュリティと言っても、OS、ミドルウェア、ネットワークと様々なレイヤーで対策が必要なので、一通り押さえるのは結構大変だったりします。そのくせ、サーバーの設定が原因でセキュリティ事故に繋がることは結構あります。
「サーバー触り始めたから、最低限必要なセキュリティは一通り入れたい。でも一個一個調べるの面倒だな...」
「入社後の研修でセキュリティの基礎を学んだけど、実際サーバーにおいてどんな設定が必要か全然わかってない...」
学生時代や研修等で知識はあっても、実務経験がまだ少ない場合、こういう状況になる方も結構いらっしゃるんじゃないでしょうか？
そこで今回は、「ゼロから始めるサーバーセキュリティの入門」というテーマで、はじめに押さえるべきサーバーセキュリティの設計や設定について解説します。無理に最初から全部やる必要はないので、とっつきやすいものや興味のあるものから取り組んでみてください。
サーバーセキュリティってどんなもの？
そもそも、「サーバーセキュリティ」って具体的に何を指すのでしょうか？ここでは、「各サーバー単体で行うべきセキュリティ対策全般」としておきます。
分類の仕方として色々な切り取り方がありますが、ここでは以下の通りに分けてみます。
OSのセキュリティ設定
ミドルウェアのセキュリティ設定
ネットワークのセキュリティ設定
認証/認可の設定
ログと監査の設定
ちなみに、「各サーバー内で行うべきセキュリティ対策」以外で、インフラ担当で行うべきセキュリティ対策としては以下のようなものがあります。
サーバ単体ではなく、クライアント/サーバー構成や専用のソフトウェアを使って行うセキュリティ対策設定（SIEM、ウイルス対策、バックアップ等）
ネットワーク機器におけるセキュリティ対策（ルーター、ファイアウォール、ロードバランサー、IDS/IPS等）
クラウド側のセキュリティ対策（クラウドでシステムを構築する場合。AWSでいうとAWS Security Hub、Amazon GuardDuty等）
ここまで語ると発散してしまうので、これらの内容は別の機会に説明したいと思います。
また、サーバーでのセキュリティ対策といっても、Linux/Windowsで設定方法やツールは異なります。今回は、触っているサーバーエンジニア人口が比較的多いであろうLinuxに軸を置いて説明します。
サーバーで行うセキュリティ対策一覧
OSのセキュリティ設定
OSのセキュリティ設定というと色々なものがありますが、代表的な例としては以下のようなものがあります。
ファイルパーミッション設定は最小権限の原則で
基本のことですが、ファイルのパーミッションはちゃんと気に掛けるようにしましょう。ことあるごとにPermission deniedを食らうとイライラしてきて脳死でchmod 777にしたくなってくる、という気持ちは痛いほどわかりますが、万が一緩いパーミッションが原因で、攻撃や内部不正によって情報漏洩が発生したら後悔してもしきれません。
それに、パーミッションが緩いとそもそも使えないものもあります。代表的な例としてはSSH鍵です。EC2サーバーから他のEC2サーバーにSSHアクセスしようとしたときに、SSH鍵のパーミッションが緩いままだと、以下のようなメッセージが出てSSHログインさせてくれません。
この場合は「chmod 400 test-key.pem」コマンドでパーミッション設定するとSSHログインが可能になります。
セキュリティ対策としてはもちろん、SSH鍵のように作業自体NGとなるものもありますので、基本的に、chmod、chownを使って常に必要最小限の権限に絞る習慣をつけましょう。
セキュリティパッチ運用はシステム特性に合わせて適切なルールを定める
「パッチはできるだけすぐ当てて、最新の状態にしよう！」というのはセキュリティ対策の話になるといつも言われることですが、実際はそんなに単純なものでもありません。なぜならパッチ適用は以下のようなデメリットがあるからです。
パッチを適用するのにもそれなりの工数がかかる
システム、業務の停止を伴うパッチもある（適用後にOS再起動が必要、等の理由で）
パッチを当てることで既存の業務アプリケーションに影響を及ぼすことがある（パッチによって、これまで使っていたコンポーネントが意図せずなくなったり変更されたりすることで）
特に2つ目と3つ目は現場やシステムによっては非常に問題視されており、金融系のように業務が止まるとすぐニュースになるようなシステムでは「安定稼働が妨げられるぐらいならパッチ適用しないほうがマシ」という考え方が残っている現場も珍しくありません。
そのため、パッチ適用において重要なのは、「常に最新の状態を目指す」のではなく、「システムや業務の特性に合わせて最適な運用で適用していく」ということになります。
具体的なパッチ運用ルールとしては、以下のようなものがあります。
パッチ適用は緊急性の高いもののみ週次で適用し、それ以外のものは月次で適用する
システムの再起動を伴うパッチは、最も業務利用の少ない時間帯に実施する
セキュリティパッチは、必ず週次/月次のパッチ運用で早々に取り込むが、不具合/バグ修正のパッチ適用は必要性に応じて実施タイミングを判断する
これは「サーバーセキュリティの入門」というには少し発展的かもしれませんが、システム運用に携わる場合は必ず考えることになることになるので、ぜひ覚えておいてください。また、OSのセキュリティ対策の位置づけで紹介しましたが、ミドルウェアやソフトウェアのパッチ適用も考え方は概ね同じです。
不要なサービスは停止する
標準で有効化されているサービスについて、中には該当のサーバーの役割にとっては不要なものも含まれています。普通にシステムを動かすうえでは害がないこと、「実は使っていた」ということがあると怖いことなどを理由に有効化されっぱなしになるケースもありますが、ちゃんと無効化しておきましょう。
というのも、攻撃者にとっては動いているサービスが多いほど、攻撃の足掛かりになるものが多いということになるからです（アタックサーフェスと呼んだりします）。確実に動作影響のない不要サービスを探して無効化していく作業は地味で苦痛かもしれませんが、セキュリティ対策として重要ですので取り組むようにしましょう。
ミドルウェアのセキュリティ設定
次にミドルウェアのセキュリティ設定について説明します。ミドルウェアといっても、システムによって利用しているものは非常に様々ですので、多くのミドルウェアに共通するものについて紹介します。
製品名やバージョン情報は見せない
サイバー攻撃を仕掛ける場合、攻撃者は既知の脆弱性情報があればそれを活用しようとします。その際、製品のバージョン情報というのは攻撃者にとって非常に有益な情報となります。
例えば、WebサーバのApacheはデフォルトのエラー画面のフッターでこんな情報を返してしまう設定になっていることがあります。
Apache/2.4.41 (Ubuntu) Server at ...これは「このサーバはApacheのバージョン2.4.41で、Ubuntu上で動いていますよ」ということを利用者に教えてしまっているのと同じです。該当のApacheバージョンやUbuntuの既知の脆弱性を探して攻撃しやすくなってしまいます。
例えばApacheなら設定ファイル（httpd.conf）で「ServerSignature Off」という設定を入れることでエラー画面のフッターから前述のような製品名/バージョン名情報を削除できます。また、「ServerTokens Prod」という設定により、HTTPレスポンスヘッダーにバージョン情報を含めないようにすることもできます。
製品によって実装方法は異なりますが、「基本的に製品名とバージョンを見せるということは脆弱性をさらしているのと同じである」というのは必ず認識しておき、画面にしろレスポンスにしろ、製品名やバージョンが含まれているのを見つけたら「隠す実装にできないか？」を考えるように癖付けましょう。
不要なモジュール/機能は無効化する
考え方はOSにおける不要なサービスの無効化と同じです。企業で利用しているサーバーではあんまりないと思いますが、「使っているかわからないけどとりあえず有効化していたモジュール」とかがあると危ないので注意です。
ネットワークのセキュリティ設定
続いてネットワークレイヤーのセキュリティ設定の話をします。前述の通り、あくまでサーバー単体で行う対策であって、ルータやファイアウォールなどのネットワーク機器での対策は含みません。
不要な通信許可は塞いでおく
基本中の基本ですが、アクセスさせる必要がない送信元IPアドレスや宛先ポートを許可しっぱなしにしておくのはやめましょう。firewalldやAWSのセキュリティグループなどを利用して各サーバー単位で通信制御をします。
「当たり前だろそんなもん！！」と思った方も多いかと思いますので、一つありがちじゃないかと思う例を挙げておきます。ICMPだけは広く許可しちゃうパターンです。
ICMPはネットワーク疎通確認や障害切り分けの時に非常に役に立つので、ICMPだけは送信元Anyで許可したままという環境もまだまだ少なくないと思いますが、ICMP Flood攻撃やPing of Death攻撃の的になりうるので、ICMPも本当に必要なものに絞ったほうが良いです（本当に必要なものの例で言うと、Pingで生死監視しているとかですね）。
ただ、正直これに関しては運用の便利さとセキュリティのどちらを重視するかで判断が分かれるものでしょう。私はネットワークエンジニア歴が長いので、個人的には危険性は分かっていてもICMPを封印するのは非常に抵抗があります...笑
出来れば通信は暗号化する
万が一通信を盗聴されたときに備え、通信は極力暗号化することが望ましいです。今時クライアント⇒Webサーバまでを暗号化せずHTTPとしていることはさすがにほとんど無いと思いますが、システム内部、つまりファイアウォールやロードバランサー-Web間、Web-AP間、AP-DB間等が暗号化されてないことはまだまだあるでしょう。
境界型防御の時代はこれでも良かったですが、ゼロトラストの考えが浸透してきている今、LBやサーバ間の通信も含めてエンドツーエンドで暗号化することにも対応できるようになっておいた方がいいです。具体的にはSSL-VPNやTLSベースのAP、DBサーバー間暗号化通信、最近はmTLSとかもコンテナ通信（サービスメッシュ）とかで使われていますね。
ちなみに、これはどちらかというと本番システム向けというよりエンジニア個人作業向けの小ネタレベルの話ですが、SSHポートフォワーディングを使う癖をつけておくと何かと捗ります。SSHポートフォワーディングには以下のようなメリットがあります。
暗号化するのがハードルが高い、あるいは暗号化に労力をかけるほど大事なシステムでないものでも、手軽にSSHで暗号化できる（例えば古いサーバーで管理画面へのアクセスがHTTP一択になってしまう場合にも暗号化できる）
環境の制約でSSHでしかアクセスできないサーバに対し、ファイアウォールをいじらなくてもWebアクセスやRDPアクセスができる
※前提として、SSH（tcp22）アクセスが許可されている必要があることはご注意ください
SSHポートフォワーディングのやり方はTeratermやPutty等のツールにも依存するのでここでは割愛しますが、検索すると仕組みややり方も含めて解説記事が大量に出てくるので、知らなかった方はぜひ試してみてください。
認証/認可の設定
不正アクセスというのはあらゆる攻撃の入口になる超危険なもので、それを成功させないための仕組みこそ認証/認可です。基本ですがしっかり把握しておきましょう。
SSHにおけるrootログインを禁止する
ド定番ですが、簡単なので必ずやっておきましょう。Linuxだと/etc/ssh/sshd_configファイルでPermitRootLoginをnoとするだけですね。
SSHアクセスは公開鍵認証で行う
SSHでアクセスするときはパスワード認証か公開鍵認証を選択できますが、原則公開鍵認証としましょう。やはりパスワード一本はパスワードリスト攻撃に弱いので怖いです。
公開鍵認証でのSSHアクセスは、最初は難しく見えるかもしれないですがシンプルです。以下に簡単な例を示します。
また、/etc/ssh/sshd_configファイルでSSHのパスワード認証を禁止することが出来ます。以下の通り、PasswordAuthenticationをnoにするだけです。
運用上、公開鍵認証に限定するのであればここも併せて行いましょう。
ログと監査の設定
最後はログと監査について語ります。
出すべきログを必要最小限に出す
セキュリティの観点でいうと、ログというのは出しすぎても出さなすぎてもNGです。
出しすぎ： 重要情報を見せるべきでない相手にも見せてしまうことで攻撃や内部不正のリスクがある（例：認証情報や個人情報がログに出ていたり、外部や非特権ユーザーから参照可能な場所に置いてあったり）
出さなすぎ： 障害時やセキュリティ事故の時に重要な情報や証跡がログに残ってないので調査が難航するリスクがある（例：ブルートフォース攻撃が行われた時間の把握のために、短期間で大量のログイン失敗があった時間帯を知りたいが、ログインイベントは成功時のみログに出力していて失敗時のログを書かない設定になっていたので、追うことが出来なかった）
「出しすぎ」の対策は、単純にテストで出力されたログから「まずいものがないか？」を確認するだけで済みます。が、「出さなすぎ」の対策は意外と難しいです。なぜなら、障害時やセキュリティ事故の具体的なイメージをしたうえで、どんな情報が必要かをあぶりだす必要があるからです。「どんな攻撃/脅威に備えるか？」「その場合、どんなログがあれば調査が可能か？」というところまで踏み込んで対策する必要があります。入門レベルとしては、「調査に必要なログはちゃんと出さないといけない」と意識づけしてくだけでも十分でしょう。
監査ログの出力/改ざん検知対策を行う
監査は「誰が、いつ、何をしたか」を知るための仕組みです。不正アクセスや誤操作の証跡を追うための監査ログや、ファイルの変更を監視する改ざん検知などの機能が監査のための仕組みに該当します。
Linuxにおける監査といえばauditdが有名です。ユーザーが実行したコマンドの記録や、特定のファイルの変更を検知してログに残す等の機能を持っています。
監査ログやファイル変更監視は、うまく運用しないと「予定作業なのに検知してしまい、余計なアラート対応に追われた」ということを繰り返して、だんだん警戒心が下がっていって、いつか本当に不正アクセスがあった時に対応が遅れた、ということもあり得るので、導入には注意が必要です。具体的には「正常作業の間だけ改ざん検知のアラートを止める、または変更監視対象から外す」とかいった仕組みにするのが良いでしょう。
よくある疑問・注意点（Q&A）
Q1: オンプレミス向けの内容に感じるが、クラウドだとどうなのか？
A:クラウドにおいても、特にIaaS（AWSのEC2等）ではOS以上の世界は一緒なので、やるべきセキュリティ対策は一緒です。ただし、エンジニア自身でやらなきゃいけないことは減っています。というのもある程度のセキュリティ対策はデフォルトで入ってることも多いからです。例えばEC2だと、SSHログインはデフォルトで公開鍵認証方式になっていますし、rootユーザーでのログインもデフォルトで禁止されています。
Q2: Windowsの場合は何が変わるの？
A:LinuxとWindowsでは各種ツールや機能、呼び名は全然違いますが、基本的に考え方は一緒です。Linux側でサーバーセキュリティの観点や原則を押さえておけば、Windowsで対策するときも「Linuxにおける●●ってWindowsの▲▲ね」とすぐに応用できます。しいて言うならActive Directory周りが少々独特かな？ぐらいです。
Q3: ここに書いてあるレベルは大体押さえた。次は何をすべき？
A: 今回のテーマは「各サーバー内で行うべきセキュリティ対策」を挙げましたが、実際にはサーバー単独ではカバーできないインフラレイヤーでのセキュリティ対策はたくさんあります。
冒頭にも書きましたが、インフラ全体のセキュリティ対策の知識をつけたい場合、以下のようなところを勉強/実践していくと良いでしょう。
サーバ単体ではなく、クライアント/サーバー構成や専用のソフトウェアを使って行うセキュリティ対策設定（SIEM、ウイルス対策、バックアップ等）
ネットワーク機器におけるセキュリティ対策（ルーター、ファイアウォール、ロードバランサー、IDS/IPS等）
今日から実践！
サーバーセキュリティ入門のチェックリスト
OSのセキュリティ設定
ファイルパーミッション設定は最小権限の原則で
セキュリティパッチ運用はシステム特性に合わせて適切なルールを定める
不要なサービスは停止する
ミドルウェアのセキュリティ設定
製品名やバージョン情報は見せない
不要なモジュール/機能は無効化する
ネットワークのセキュリティ設定
不要な通信許可は塞いでおく
出来れば通信は暗号化する
認証/認可の設定
SSHにおけるrootログインを禁止する
SSHアクセスは公開鍵認証で行う
ログと監査の設定
出すべきログを必要最小限に出す
監査ログの出力/改ざん検知対策を行う
まとめ： サーバーセキュリティの基礎を押さえたら、深掘りしたり横に広げたりするのも良し
今回はサーバーセキュリティの入門というテーマでご紹介していきました。サーバーセキュリティといっても、高度な攻撃も見据えると非常に奥の深いテーマで、今回触れることが出来なかったものもたくさんあります（HW/ファームウェアのような物理寄りのセキュリティ、カーネルのセキュリティ等）。もっとサーバー内のセキュリティを極めたい人は、書籍を買って勉強したり、攻撃者側の勉強をして脆弱性に詳しくなったりと、色々な角度から勉強してみると理解が深まって面白いと思います。
とはいえ、入門レベルとして最低限押さえるべきセキュリティには触れたつもりです。「今回のでお腹いっぱい...」という方は、気分転換にネットワーク機器やクラウド等の別のカテゴリのセキュリティに触れるとか、あるいは一旦また動かすほうの勉強に力を入れるというのもアリだと思います。
今回の記事が、サーバーセキュリティの基礎を押さえたい方にとって少しでも有益なものになっていれば嬉しいです。最後までお読みいただき、ありがとうございました。
