お声がけをいただいて,
インフラもセキュリティもなんでもそうですが,
ただ,
本連載では,
と言うことで,
1.ソフトウェアの脆弱性とその修正
バグのないソフトウェアはないと言うくらいに,
例外はあるものの,
- 注1)
- 経済産業省告示第二百三十五号 ソフトウエア等脆弱性関連情報取扱基準
(PDF)
(1)ソフトウェアのバージョンアップ
たとえば,
ソフトウェアのバージョンアップによる脆弱性対応を行う場合には,
(2)ソフトウェア以外の部分での対応
ソフトウェアをバージョンアップできないような環境の場合には,
たとえば,
(3)ソフトウェアパッケージの入れ替え
これは,
(4)攻撃の監視
(1)~
ただし,
ソフトウェアパッケージとはなにか?
ソフトウェアパッケージは,
たとえばRed Hat Enterprise LinuxやCentOSでは.rpmと言うサフィックスを持ったファイル
そして,
通常,
2.通常のソフトウェア脆弱性対処とOSごとの対処
ソフトウェアに脆弱性が発見された際には,
しかし,
とは言え,
以下,
(1)バージョンアップ
OSSやFSWの場合,
- (A)
利点 (a) 既知の脆弱性による影響をなくすことが可能 (b) バージョンアップにより提供される新しい機能を利用可能になる
- (B)
欠点 (a) 脆弱性修正以外に出てくる影響を見極めるためには, Changelogやソースコードをきちんと読み解く必要がある (b) コンパイルを行う際の環境構築や入れ替えにスキルが必要 (c) 入れ替えに伴う他のソフトウェアへの影響確認が大変 (d) 依存関係の解決が大変になることがある
ソースコードをコンパイルするには,
単なるコマンド1つの入れ替えで済めば良いのですが,
とくに,
(2)パッケージ入れ替え
ここでのパッケージは,
- (A)
利点 (a) 既知の脆弱性による影響をなくすことが可能 (b) バージョンアップではないため, パッケージ入れ替えに伴う確認は, 最小限の動作確認で済む (c) 依存関係の解決は, パッケージマネージャに任せることが可能
- (B)
欠点 (a) コンパイル済みのバイナリ+設定ファイルと言う組み合わせが提供されるため, パッケージ入れ替えで何が差し替わるかをきちんと確認する必要がある (b) ソフトウェアをパッケージではなくソースコードからのコンパイルを行って導入している場合には, すでに入っているソフトウェアを消去するか無効にする必要がある (c) バージョンアップするわけではないため, 脆弱性対応は行えるが, バージョンアップを行うことで使用可能になるような機能は使えない
RPMパッケージやDEBパッケージは,
これは,
運用上,
筆者もシステム運用の経験は山のようにありますが,
パッケージマネージャに任せることで,