Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
openSUSE Leap ドキュメンテーション › セキュリティ強化ガイド › ローカルセキュリティ › 物理的なセキュリティ
コンテンツコンテンツ
セキュリティ強化ガイド
  1. 前書き
  2. 1 セキュリティと機密保持
  3. I 認証
    1. 2 PAM を利用した認証
    2. 3 NIS の使用
    3. 4 YaST を利用した認証クライアントの設定
    4. 5 389 Directory Server を利用した LDAP サービス
    5. 6 Kerberos を利用したネットワーク認証
    6. 7 Active Directory サポート
    7. 8 FreeRADIUS サーバの構築
  4. II ローカルセキュリティ
    1. 9 物理的なセキュリティ
    2. 10 ソフトウエア管理
    3. 11 ファイルの管理
    4. 12 パーティションやファイルの暗号化
    5. 13 cryptctl を利用したアプリケーション向けのストレージ暗号化
    6. 14 ユーザ管理
    7. 15 cron と at の制限
    8. 16 Spectre/Meltdown チェッカー
    9. 17 YaST を利用したセキュリティの設定
    10. 18 Polkit 認可フレームワーク
    11. 19 Linux でのアクセス制御リスト
    12. 20 AIDE を利用した侵入検知
  5. III ネットワークセキュリティ
    1. 21 X Window System と X 認証
    2. 22 OpenSSH によるネットワーク操作の機密保持
    3. 23 マスカレードとファイアウオール
    4. 24 VPN サーバの設定
    5. 25 X Window System で動作する PKI マネージャ XCA による管理
    6. 26 sysctl 変数によるネットワークセキュリティの改善
  6. IV AppArmor による権限の制限
    1. 27 AppArmor の紹介
    2. 28 入門
    3. 29 プログラムに対する予防接種
    4. 30 プロファイルのコンポーネントと文法
    5. 31 AppArmor のプロファイルリポジトリ
    6. 32 YaST を利用したプロファイルの構築と管理
    7. 33 コマンドラインからのプロファイル構築
    8. 34 チェンジハット機能による Web アプリケーションのプロファイル作成
    9. 35 pam_apparmor によるユーザの制限
    10. 36 プロファイルを作成したアプリケーションの管理
    11. 37 サポート
    12. 38 AppArmor 用語集
  7. V SELinux
    1. 39 SELinux の設定
  8. VI Linux 監査フレームワーク
    1. 40 Understanding Linux audit
    2. 41 Linux 監査フレームワークの設定
    3. 42 監査ルールセットの紹介
    4. 43 その他の情報源
  9. A GNU ライセンス
ナビゲーション←→
openSUSE Leap ドキュメンテーション › セキュリティ強化ガイド › ローカルセキュリティ › 物理的なセキュリティ
トップへ
←→
適用先 openSUSE Leap 15.6

9 物理的なセキュリティ Edit source

9.1 システムの施錠
9.2 BIOS のロックダウン
9.3 ブートローダでのセキュリティ
9.4 機密データを含む Linux サーバの廃棄
9.5 リムーバブルメディアへのアクセス制限
9.6 USBGuard による USB デバイスの認可とシステムの保護

物理的なセキュリティ確保はとても重要です。 Linux の本番サーバは、セキュリティチェックを通過した人間のみがアクセスできる、鍵のかかったデータセンター内に配置されるべきです。環境や状況にもよりますが、ブートローダに対してパスワードを設定することも検討すべきです。

上記に加えて、下記を考慮する必要もあります:

  • ホストに対して直接アクセスできるのは誰か？

  • その彼らがすべきことは？

  • ホストを改ざんから保護することができるか？

特定のシステムにおける物理的なセキュリティは、そのシステムが配置されている状況に依存して決まるほか、利用可能な予算によっても大きく異なります。

9.1 システムの施錠 Edit source

データセンター内のほとんどのサーバラックには施錠の機能が備わっています。通常はラックの前面に掛け金やシリンダー錠の形式で用意され、施錠や解錠を行うことで内部へのアクセスを許可したり禁止したりすることができます。かご形のラックであればサーバからデバイスを不正に差し替えたり抜きとったりすることを防げますし、筐体を開けたり妨害したりすることも防ぐことができます。また、システムを不正に再起動されたり、代替デバイス (例: CD/DVD/USB メモリなど) から起動できたりしないようにすることも重要です。

サーバによってはケースロック (施錠) を備えているものもあります。これらのロックはシステムの製造元や構造によって異なるもので、ほとんどのケースロックは筐体を開けなくする目的で提供されていますが、キーボードやマウスなどを接続できないようにするものもあります。施錠は便利な仕組みではありますが、安全性という観点では低く、悪意のある人間であれば難なく突破できてしまう程度の仕組みでもあります。

9.2 BIOS のロックダウン Edit source

ヒント
ヒント: Secure Boot

本章では起動処理の安全性を高めるための基本的な方式のみを説明しています。 UEFI を利用したより高度な起動保護方法や Secure Boot 機能そのものの説明については、 14.1項 「Secure Boot」 をお読みください。

BIOS (Basic Input/Output System) やその後継である UEFI (Unified Extensible Firmware Interface) は PC システムで最も低い位置にあるソフトウエア／ファームウエアです。 Linux の動作する他のハードウエアタイプ (POWER, IBM Z) にも、 PC BIOS と似たような機能を持つ低レベルのファームウエアがあります。この文書内で "BIOS" と記述した場合、通常は BIOS と UEFI の両方を意味します。 BIOS はシステムの設定を構成して一定の状態にするほか、低レベルなハードウエア機能も提供します。 BIOS はその後、ホストを起動するための Linux ブートローダ (例: GRUB 2) を開始します。

ほとんどの BIOS 実装には、システムの不正な操作や不正な起動設定を防止するための機能が用意されています。一般には BIOS 管理者パスワードや起動パスワードなどと呼ばれています。管理者パスワードはシステムの設定を変更する際に求められるパスワード、起動パスワードは通常の起動を行う際に求められるパスワードです。ほとんどの場合、管理者パスワードのみを設定し、内蔵のハードディスクからのみ起動するよう設定すれば十分です、これにより、 Linux のライブ CD や USB メモリなどを挿入もしくは接続して不正に起動するのを防ぐことができます。ただし、 BIOS は高度なセキュリティを提供するものではなく、筐体を開くだけで容易に BIOS をリセットできたりパスワードを削除もしくは変更できたりしてしまうため、他の仕組みと組み合わせて使用する必要があります。

多くの BIOS ファームウエアには、それ以外のセキュリティ関連の設定が用意されています。システムの製造元や提供されているマニュアル、もしくは BIOS のメニューなどを参照して、どのような設定ができるのかをご確認ください。

重要
重要: BIOS の起動パスワードを設定した場合の起動について

システムに対して起動パスワードを設定すると、そのシステムは無人では起動しなくなってしまいます (たとえばシステムの再起動や電源障害などの場合、自動では起動しなくなってしまいます。これは安全性と利便性のトレードオフとなります。

重要
重要: BIOS 管理者パスワードを紛失した場合について

システムを初めて設定したような場合、 BIOS の管理者パスワードはそれほど頻繁に入力する必要はありません。そのため、パスワードを忘れてしまわないように注意してください。パスワードを忘れてしまった場合、再度アクセスできるようにするには、ハードウエア側の操作を行って BIOS の設定を消去する必要があります。

9.3 ブートローダでのセキュリティ Edit source

openSUSE Leap の既定で使用される Linux のブートローダ GRUB 2 には、起動パスワードを設定する機能が用意されています。パスワード機能を利用することで、管理者のみが対話的な操作 (例: メニュー項目の編集やコマンドラインインターフェイスでの入力など) を行うことができるようにすることができます。またパスワードを指定した場合、 C および E を押して正しいパスワードを入力するまで、いかなる対話的な操作も禁止されるようになります。

詳しい設定については、 GRUB 2 のマニュアルページをお読みください。

なお、パスワードを設定するにあたっては、設定したパスワードを忘れてしまわないように注意してください。また、パスワードを設定しても、侵入への時間を稼ぐことができるだけであって、完全に防げるわけではないことにも注意してください。たとえばリムーバブルデバイスから起動できる環境であれば、リムーバブルメディアを挿入してルートパーティションをマウントできてしまいます。このような場合は、 BIOS レベルのセキュリティとブートローダのセキュリティの両方を使用することで、リムーバブルメディアからの起動を禁止して、かつ BIOS と起動の両方をパスワードで保護することができるようになります。

このほか、ブートローダの設定ファイルには適切なパーミッション 600 (root のみが読み書きできる) を設定して保護する必要もあります。保護を行わないと、パスワードやハッシュを読み取られてしまいます。

9.4 機密データを含む Linux サーバの廃棄 Edit source

セキュリティポリシーには通常、廃棄予定のストレージメディアの取り扱いに関する規定も記述されています。ディスクやメディアの消去手順は、メディアの完全破壊としてもよく知られています。インターネット上にはさまざまなツールが提供されていますので、 「ディスク 消去 ユーティリティ」 などで検索を行うと、それらのツールに関する説明を読むことができます。機密データを含むサーバを廃棄する場合、ディスク内に書かれていたデータを修復できないようにすることが重要です。全てのデータの痕跡を消去するには、 scrub などのユーティリティをお使いください。多くの消去ツールは、データ領域に上書きで何度も書き込むことによって消去を行います。これにより、高度な方法でデータにアクセスしようとしても、データを全く読み取れなくなります。ツールによっては単独で起動できる媒体が提供されているものや、アメリカ国防総省 (U.S. Department of Defense) 標準に準拠してデータを消去する機能を備えているものもあります。なお、それぞれの政府機関では独自に消去標準を策定しています。標準によってはそれより強力なものもありますが、強力であればあるほど時間のかかるものであることに注意してください。

重要
重要: ウエアレベリング機能を持つデバイスでの消去について

SSD などのデバイスにはウエアレベリングと呼ばれる仕組みがあり、データの上書きを行っても同じ場所に書き込まれるとは限らないものがあります。このようなデバイスの場合は、独自の機能を利用して消去する必要があります。

9.4.1 scrub: ディスクの上書きユーティリティ Edit source

scrub コマンドはハードディスクやファイルのほか、その他のデバイスに対しても利用可能なユーティリティで、データの復元を難しくするために繰り返しパターンを書き込むことで上書きを行います。このユーティリティは 3 種類のいずれかのモードで動作させることができます。モードはキャラクタ／ブロックデバイス、ファイル、ディレクトリのいずれかです。詳しくは man 1 scrub で表示されるマニュアルページをお読みください。

対応する消去方式
nnsa

国家核安全保障局 (NNSA) が NAP-14.1-C (XVI-8) として規定される方式で、リムーバブルメディアや非リムーバブルメディア (ハードディスク) に対応しています。全ての場所に対して擬似乱数パターンを 2 回、その後既知のパターンを書き込む 4 パス型の方式です: 乱数 (x2), 0x00, 書き込み検証

dod

DoD 5220.22-M section 8-306 procedure (d) として規定される方式で、リムーバブルメディアや非リムーバブルメディア (ハードディスク) に対応しています。書き込み可能な全ての範囲に対して、特定の文字、その反転パターン、ランダムな文字をそれぞれ書き込んで、最後に検証を行う 4 パス型の方式です。注意: scrub では書き込み検証を容易に実施できるよう、乱数のパスを最初に実行します: 乱数, 0x00, 0xff, 書き込み検証

bsi

German Center of Security in Information Technologies ( https://www.bsi.bund.de ) が推奨する 9 パス型の方式です: 0xff, 0xfe, 0xfd, 0xfb, 0xf7, 0xef, 0xdf, 0xbf, 0x7f

gutmann

Gutmann 氏の論文で示された方式で、合計 35 パスの手順を踏む方式です。

schneier

Bruce Schneier 氏の "Applied Cryptography" (1996) で示された 7 パス型の方式です: 0x00, 0xff, 乱数 (x5)

pfitzner7

Roy Pfitzner 氏による 7 乱数パス型の方式です: 乱数 (x7)

pfitzner33

Roy Pfitzner 氏による 33 乱数パス型の方式です: 乱数 (x33)

usarmy

アメリカ陸軍の AR380-19 方式です: 0x00, 0xff, 乱数 (注意: 磁気コアメモリを消去する場合は、 DoD 522.22-M section 8-306 procedure (e) と等価になります)

fillzero

1 パス型のパターンです: 0x00

fillff

1 パス型のパターンです: 0xff

random

1 パス型のパターンです: 乱数 (x1)

random2

2 パス型のパターンです: 乱数 (x2)

old

バージョン 1.7 以前の scrub と同じ 6 パス型の方式です: 0x00, 0xff, 0xaa, 0x00, 0x55, 書き込み検証

fastold

5 パス型の方式です: 0x00, 0xff, 0xaa, 0x55, 書き込み検証

custom=(文字列)

1 パス型の独自パターンです。 (文字列) には C 形式の数値エスケープ (\nnn (8 進数) もしくは \xnn (16 進数)) を記述することができます。

9.5 リムーバブルメディアへのアクセス制限 Edit source

環境によっては、 USB ストレージや光学メディアなどのリムーバブルメディアへのアクセスを制限する必要があることがあります。このような場合は、 udisks2 パッケージを利用することで、設定を行うことができます。

  1. まずはリムーバブルメディアをマウントしたり取り出したりすることができるユーザグループを作成します。下記の例では、 mmedia_all というグループを作成しています:

    > sudo groupadd mmedia_all

  2. 次に tux を新しいグループに追加します:

    > sudo usermod -a -G mmedia_all tux

  3. /etc/polkit-1/rules.d/10-mount.rules ファイルを作成して、下記のような内容を記述します:

    > cat /etc/polkit-1/rules.d/10-mount.rules
polkit.addRule(function(action, subject) {
 if (action.id =="org.freedesktop.udisks2.eject-media"
  && subject.isInGroup("mmedia_all")) {
   return polkit.Result.YES;
  }
});

polkit.addRule(function(action, subject) {
 if (action.id =="org.freedesktop.udisks2.filesystem-mount"
  && subject.isInGroup("mmedia_all")) {
   return polkit.Result.YES;
  }
});
    重要
    重要: ルールファイルの命名について

    ルールファイルのファイル名は必ず数字で始まっていなければなりません。数字で始まっていないファイル名の場合、そのファイルは無視されます。

    ルールファイルはアルファベット順に処理されます。関数はいずれかの関数が値を返すまで、処理された順序で実行されます。そのため、特定のルールよりも前に処理させたい認可ルールがある場合は、そのルールファイルよりも前に並ぶファイル名を設定して /etc/polkit-1/rules.d 内に配置してください。たとえば /etc/polkit-1/rules.d/10-mount.rules のようになります。また、それぞれの関数は polkit.Result の値を返す必要があります。

  4. udisks2 を再起動します:

    # systemctl restart udisks2

  5. polkit を再起動します

    # systemctl restart polkit

9.6 USBGuard による USB デバイスの認可とシステムの保護 Edit source

USBGuard ソフトウエアフレームワークは、 USB デバイスの認可を強制することによって、お使いのシステムを保護する機能を提供します。このフレームワークは、デバイスの属性情報をベースにした許可／拒否リストを使用します。

USBGuard には下記のような機能があります:

  • 動作中の USBGuard デーモンとの対話を行うためのコマンドラインインターフェイス

  • 動的な処理やポリシー強制を行うためのプロセス間通信 (IPC) 機能を持ったデーモンコンポーネント

  • USB デバイスの認可ポリシーを記述するためのルール言語

  • 共有ライブラリとして提供された、デーモンコンポーネントとの対話を行うための C++ API

9.6.1 USBGuard のインストール Edit source

USBGuard デーモンは、ポリシー内に規定されたルールをもとに、 USB デバイスの使用可否を判断します。 USBGuard をインストールして設定するには、下記のコマンドを使用してください:

  1. USBGuard をインストールするには、下記の手順を実施します:

    > sudo  zypper install usbguard

    これで USBGuard と必要な依存関係がインストールされます。 USBGuard サービスとの対話を行うには、 usbguard-tools も合わせてインストールしてください。

  2. 現在接続されている USB デバイスを元にしてルールセットを生成したい場合は、 root に切り替えて下記のコマンドを実行します:

    # usbguard generate-policy > /etc/usbguard/rules.conf
    注記
    注記

    あとは必要に応じて /etc/usbguard/rules.conf ファイルを編集し、 USBGuard のカスタマイズを行ってください。

  3. USBGuard の開始やシステム起動時の自動開始を設定したい場合は、 root に切り替えて下記のコマンドを実行します:

    # systemctl enable --now usbguard.service

  4. なお、 USBGuard ではデバイスの許可か拒否をそれぞれ設定することができます。これは usbguard-daemon.conf ファイル内の ImplicitPolicyTarget オプションの値によっても影響を受けますが、これはポリシー内のどのルールにも該当しなかった場合の取り扱いを指定します。

    usbguard allow-device 6
    usbguard block-device 6

    システムへの接続を拒否してデバイスを取り外したい場合は、 reject-device オプションを設定してください。

    注記
    注記

    なお、全てのオプションを確認したい場合は、 usbguard --help コマンドを実行してください。

9.6.2 USBGuard の使用方法 Edit source

デバイスの属性をベースにして allow (許可) または block (拒否) を設定することで、お使いのシステムに対する USB デバイスの接続ポリシーを設定することができます。

9.6.2.1 USBGuard の設定ファイル Edit source

USBGuard はコマンドラインオプションの解釈とデーモンへの設定適用が完了すると、 usbguard-daemon.conf ファイルの読み込みを行います。このファイルは既定で /etc/usbguard/usbguard-daemon.conf に配置します。このファイルには下記のようなオプションが含まれています:

オプション
RuleFile=パス

USBGuard デーモンは、このファイルをポリシールールセットの読み込み元として使用するほか、 IPC (プロセス間通信) で指示された新しいルールの書き込み先としても使用します。既定値は %sysconfdir%/usbguard/rules.conf になります。

ImplicitPolicyTarget= ターゲット

ポリシー内のどのルールにも該当しないデバイスの取り扱い方法を指定します。たとえば下記のようになります:

  • allow - デバイスの接続を許可します

  • block - デバイスの接続を拒否します

  • reject - システムからデバイスノードを論理的に削除します

PresentDevicePolicy= ポリシー

デーモンの起動時に既に接続されていたデバイスの取り扱い方法を指定します。

  • allow - デバイスの接続を許可します

  • block - デバイスの接続を拒否します

  • reject - デバイスを削除します

  • keep - 内部状態を同期させます

  • apply-policy - 全ての既存デバイスに対して、ルールセットを適用します

IPCAllowedUsers= ユーザ名

デーモンに対して IPC 経由でコマンドの送信を許可するユーザ名を、スペース区切りで指定します。

IPCAllowedGroups= グループ名

デーモンに対して IPC 経由でコマンドの送信を許可するグループ名を、スペース区切りで指定します。

IPCAccessControlFiles= パス

IPC のアクセス制御設定ファイルとしてデーモンが解釈すべきファイルパスを指定します。

例 9.1: 設定 
IPCAllowedUsers=root joe
IPCAllowedGroups=wheel

たとえば上記のような例の場合、 root , joe の各ユーザ、および wheel グループに属するユーザからの全ての IPC を許可します。

9.6.3 さらなる情報 Edit source

USBGuard に関するさらに詳しい情報を参照したい場合は、それぞれ下記をご覧ください:

  • 提供元のドキュメンテーション: https://usbguard.github.io/

  • man usbguard

  • man usbguard-rules.conf

  • man usbguard-daemon

  • man usbguard-daemon.conf

→第10章 ソフトウエア管理←パート II ローカルセキュリティ
このページを印刷

© 2024 SUSE