Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

2.11. セキュリティーおよびアクセス制御

このセクションでは、Red Hat Enterprise Linux 6 と Red Hat Enterprise Linux 7 との間でなされたセキュリティー、アクセス制御、および関連設定ツールの変更の概要について説明しています。

2.11.1. 新ファイアウォール (firewalld)

Red Hat Enterprise Linux 6 では、iptables ユーティリティーがファイアウォール機能を提供し、コマンドラインもしくはグラフィカル設定ツールの system-config-firewall で設定されていました。Red Hat Enterprise Linux 7 では、iptables がファイアウォール機能を提供しています。ただし、管理者は動的ファイアウォールデーモンである firewalld と、その設定ツールである firewall-config、firewall-cmd、firewall-applet で iptables と通信します。これは、Red Hat Enterprise Linux 7 のデフォルトインストールには含まれていません。

firewalld は動的であることから、その設定はいつでも変更可能で、即座に実行されます。ファイアウォールはリロードする必要がないことから、既存のネットワーク接続で意図しない中断が発生することはありません。

Red Hat Enterprise Linux 6 と 7 間でのファイアウォールの主な相違点は以下のとおりです。

  • Firewalld 設定の詳細は /etc/sysconfig/iptables に保存されていません。設定詳細は /usr/lib/firewalld および /etc/firewalld ディレクトリーの様々なファイルに保存されます。
  • Red Hat Enterprise Linux 6 では、設定が変更される度にすべてのルールが削除され、再適用されていましたが、firewalld は設定の差異のみを適用します。その結果、firewalld は既存の接続を中断することなく、ランタイム中に設定を変更することができます。

Red Hat Enterprise Linux 7 でファイアウォールを設定するための追加情報と支援については、セキュリティーガイドを参照してください。

2.11.1.1. firewalld への移行ルール

重要

Red Hat Enterprise Linux 7 を、別の Red Hat 製品 (Red Hat Enterprise Linux OpenStack Platform など) と使用している場合は、firewalld に移行する代わりに iptables または ip6tables を引き続き使用することが適切なことがあります。

どのファイアーウォールユーティリティーを使用すればいいかわからない場合は、製品ドキュメントを参照するか、Red Hat サポートにお問い合わせください。

firewalld を無効にし、iptables または ip6tables を引き続き使用する方法については、https://access.redhat.com/articles/1229233 を参照してください。

Red Hat Enterprise Linux 6 では、以下の 2 つの方法でファイアウォールを設定していました。

  • グラフィカルの system-config-firewall ツールを使ってルールを設定。このツールは、設定詳細を /etc/sysconfig/system-config-firewall ファイルに保存し、/etc/sysconfig/iptables ファイルに iptables サービスを、および /etc/sysconfig/ip6tables ファイルに ip6tables サービスを設定していました。
  • 手動で /etc/sysconfig/iptables ファイルおよび /etc/sysconfig/ip6tables ファイルを編集 (まったくのゼロから、もしくは system-config-firewall が作成した初期設定を編集) 。

Red Hat Enterprise Linux 6 のファイアウォールを system-config-firewall で設定している場合、システムをアップグレードして firewalld をインストールした後に、firewall-offline-cmd ツールを使って、/etc/sysconfig/system-config-firewall の設定を firewalld のデフォルトゾーンに移行することができます。 

$ firewall-offline-cmd

ただし、/etc/sysconfig/iptables もしくは /etc/sysconfig/ip6tables を手動で作成または編集している場合は、firewalld のインストール後に firewall-cmd または firewall-config で新しい設定を作成するか、firewalld を無効にして旧型の iptables および ip6tables サービスの使用を継続する必要があります。新しい設定の作成または firewalld の無効化の詳細については、セキュリティーガイドを参照してください。

2.11.2. PolicyKit の変更

これまで、PolicyKit は、.pkla ファイル内のキーの値のペアを使って追加のローカル権限を定義してきました。Red Hat Enterprise Linux 7 では、JavaScript を使ってローカル権限を定義する機能が提供され、必要に応じて権限を書くことが可能になっています。

polkitd は、.rules ファイルを辞書式順序で、/etc/polkit-1/rules.d および /usr/share/polkit-1/rules.d ディレクトリーから読み込みます。2 つのファイルが同じ名前を共有している場合は、/etc にあるファイルが /usr にあるファイルよりも先に処理されます。以前の .pkla ファイルでは、最後に処理されたルールが優先されていました。新たな .rules ファイルでは、最初に合致するルールが優先されます。

移行後、既存ルールは、/etc/polkit-1/rules.d/49-polkit-pkla-compat.rules ファイルによって適用されます。このため、.rules ファイルが /usr または /etc にあり、かつそのファイル名が辞書式順序で 49-polkit-pkla-compat の先にくる場合は、既存ルールよりも優先されます。古いルールが無効にならないようにする一番簡単な方法は、他の全 .rules ファイルの名前を、49 よりも大きい番号で始めることです。

詳細については、デスクトップ移行および管理ガイドを参照してください。

2.11.3. ユーザー ID の変更

Red Hat Enterprise Linux 6 でのベースユーザー ID は 500 でした。Red Hat Enterprise Linux 7 でのベースユーザー ID は 1000 となっています。この変更にしたがい、アップグレードプロセス中に /etc/login.defs ファイルが置き換えられます。

デフォルトの /etc/login.defs ファイルを修正していない場合、このファイルはアップグレード中に置き換えられます。ベースユーザー ID の番号が 1000 に変更になり、新規ユーザーに割り当てられるユーザー ID は、1000 またはそれ以上になります。この変更前に作成されたユーザーアカウントは、現行のユーザー ID を維持し、期待通りに機能し続けます。

デフォルトの /etc/login.defs ファイルを修正している場合は、このファイルはアップグレード中に置き換えられず、ベースユーザー ID 番号は 500 のままになります。

2.11.4. libuser の変更

Red Hat Enterprise Linux 7 では、libuser ライブラリーは ldap および files モジュールの両方を含む設定、もしくは ldap および shadow モジュールの両方を含む設定をサポートしません。これらのモジュールを組み合わせるとパスワード処理に曖昧さが発生するので、そのような設定は初期化プロセス中に拒否されるようになっています。

LDAP のユーザーもしくはグループの管理に libuser を使用する場合は、files モジュールおよび shadow モジュールを、設定ファイル (デフォルトでは /etc/libuser.conf ) の modules ディレクティブおよび create_modules ディレクティブから削除する必要があります。

2.11.5. opencryptoki キーストアの変更

以前のバージョンの Red Hat Enterprise Linux は、opencryptoki 鍵ストアのバージョン 2 を使用していました。このバージョンでは、ハードウェアでセキュアキーを使用して、プライベートトークンを暗号化していました。Red Hat Enterprise Linux 7 では、ソフトウェアのクリアキーでプライベートトークンオブジェクトを暗号化するバージョン 3 が使用されます。したがって、バージョン 2 で作成したプライベートのトークンオブジェクトをバージョン 3 で使用するには、最初にバージョン 2 で作成したトークンオブジェクトを移行する必要があります。

プライベートトークンオブジェクトを移行するには、以下の手順を実行します。

  1. opencryptoki のバージョンが最新であることを確認します。 

    # yum update -y opencryptoki

  2. トークンのスロット数を確認するには、pkcsconf でトークンのスロット数を調べます。以下のコマンドを root 権限で実行します。 

    # pkcsconf -s
# pkcsconf -t

    トークンのスロット番号に注意してください。スロットの説明は (CCA) で終わります。情報フィールドは、このトークンを IBM CCA トークン として識別します。

  3. インターフェイスへのアクセスを停止するには、pkcsslotd サービスおよびすべての opencryptoki プロセスを停止します。 

    # systemctl stop pkcsslotd.service

    以下のコマンドを実行して kill ユーティリティーを停止するプロセスを特定し、適切なプロセスを終了します。 

    # ps ax | grep pkcsslotd

  4. 移行前に、CCA データストア (トークンが保存されているディレクトリー、通常は /var/lib/opencryptoki/ccatok) のバックアップを取得します。たとえば、このファイルのコピーを作成します。 

    # cp -r /var/lib/opencryptoki/ccatok /var/lib/opencryptoki/ccatok.backup

  5. 移行ユーティリティーを実行し、/var/lib/opencryptoki/ccatok ディレクトリーに変更し、移行ユーティリティーを実行します。 

    # cd /var/lib/opencryptoki/ccatok
# pkcscca -m v2objectsv3 -v

    要求されたら、セキュリティーオフィサー (SO) PIN とユーザー PIN を入力します。

  6. 古い共有メモリーファイルを削除すると、手動で /dev/shm/var.lib.opencryptoki.ccatok ファイルを削除するか、システムを再起動します。 

    # rm /dev/shm/var.lib.opencryptoki.ccatok

  7. 操作インターフェイスアクセスに戻ります。再度、pkcsslotd サービスを起動します。 

    # systemctl start pkcsslotd.service

移行の際に問題が発生した場合は、以下を確認してください。

  • コマンドを root で実行しており、root が pkcs11 グループのメンバーになっていること。
  • pkcsconf ユーティリティーが /usr/lib/pkcs11/methods/ ディレクトリーまたは /usr/sbin/ ディレクトリーのいずれかにあること。
  • トークンのデータストアが /var/lib/opencryptoki/ccatok/ ディレクトリーにあること。
  • スロット番号が指定されており、その番号が正しいこと。
  • セキュリティーオフィス (SO) PIN およびユーザー PIN が正しいことを確認します。
  • カレントディレクトリーに書き込み権限があること。