アクセス制御ソリューションなしの運営サーバーアカウント別の権限分離ガイド

運営ネットワーク、開発ネットワークの分離条件において、ネットワーク分離だけでなく、ユーザー分離も必要です。このとき、権限を分離することで統制することができます。

クラウド環境には、権限を付与する方法が2種類あります。2つの方法の特性は、以下のとおりです。

RBAC（Role-Based Access Control）：個人がシステムにアクセスできる権限を役割基準で統制します。
1. ユーザーやユーザーが属するグループに役割を割り当てて、アクセスを制御する方法です。
1. ユーザーに与えた役割に応じて資源に対するアクセスを制御します。

ABAC（Attribute-Based Access Control）：システムにアクセスできる権限をユーザー、リソース属性、環境に従って統制します。
1. オブジェクトへのアクセスのために属性を定義して、そのオブジェクトにアクセスする主体がその属性を持っているのかを検査した後、アクセス制御を実行します。
1. 属性は主体の名前、資源のタイプなど様々で、対応種類はサービスまたはプラットフォームによって異なります。

ABACへのアクセス権限を統制すると、細分化された権限を使用でき、システムのさまざまな要素を反映できますが、多くの時間と資源が費やされます。

RBACは、定義された役割に対する権限分離が可能なため、効率的に権限を付与・回収することができます。そのため、RBACを基盤とする権限分離を実行しました。

一般的に、運営サーバーは開発者のアクセスを許可しません。しかし、システム障害など予期せぬ事件によって、アクセスしなければならない状況が発生します。また、運営者によってアクセスが必要なサーバーが異なり、必要な権限も異なります。このとき、ユーザー別にグループを分けて、グループに合った権限を与えることでアクセス権限を管理できます。

会社にアクセス制御ソリューションがある場合、この製品を使用すると、権限分離・設定を自由自在に行えます。ソリューションが構築されていなくても、Linux OS自体の機能のみを使ってアカウント別の権限分離が可能です。

ファイル権限の削除

この方法を使用するためには、まずsetuid、setgid設定されているファイルの権限を削除しなければなりません。

setuidが適用されたファイルを実行すると、実行ファイルが終了するまでファイル所有者のUIDとなります。setuidが設定されたrootのファイルを実行すると、実行が終了するまで実行するユーザーのUIDがrootのUIDである0になり、root権限が与えられます。同じように、setgidは、適用されたファイルを実行すると、実行ファイルが終了するまでファイルを所有するグループのGIDとなります。

setuid, setgid ファイルの確認

find / -user root -type f \( -perm -4000 -o -perm -2000 \) -exec ls -la {} \;

措置方法

chmod -s [file name]

この設定の使用が必要不可欠な場合、特定グループでのみ使用するよう制限する方法があります。（一般ユーザーのsetuid使用を制限、任意のグループのみ可能）

chgrp [group name] [setuid file name]chmod 4750 [setuid file name]

アカウントの上限も設定する必要があります。2020年KISAが発表した「クラウド脆弱性点検ガイド」を適用した場合は、既に完了したセキュリティ設定の可能性もありますが、複数のユーザーが運営サーバーにアクセスする場合、アカウント別の上限設定の有無をもう一度確認すると良いでしょう。

/etc/pam.d/common-authauthrequiredpam_tally2.so onerr=fail even_deny_root deny=5 unlock_time=600authrequiredpam_faillock.so preauth silent audit deny=5 unlock_time=600# OSによって使用するバージョンが異なるため、バージョンを確認する必要があります。

また、セッションタイムアウトも設定する必要があります。一般的に10分を推奨していますが、会社のポリシーに従って調節することができます。

/etc/profileexport TMOUT=300

この措置が完了したら、ユーザー別に権限グループを分けます。

WhaTap Labsは、devopsチーム、開発チームの2つのグループに分けられ、一般コマンドは使用できますが、sudoコマンドは制限されています。devopsチームは運営全体を管制して障害処理を実行するため、コマンドが制限されていません。開発チームは、障害把握作業しか行わないため、下記のコマンドのみ許可されています。

cat, ps, df, du, netstat, curl

WhaTap Monitoringツールを使えば十分にログを確認できるため、ログ確認のためのコマンドは許可されておらず、サーバー設定把握のためにcatは許可されています。

開発者グループの作成

groupadd dev

グループ別のsudo権限設定

/etc/sudoers%dev ALL=NOPASSWD:/usr/bin/cat, /usr/bin/ps, /usr/bin/df, /usr/bin/du, /usr/bin/netstat, /usr/bin/curl# コマンド別のすべてのパスは、whichコマンドで確認できます。

権限付与の過程は以下のとおりです。

開発チームの権限リクエストを確認します。
1. アクセスサーバー、理由、アクセス期間が含まれる必要があります。
1. 開発チーム長、devopsチーム長から承認を得なければなりません。

リクエストされた権限の正当性を確認します。

開発チームから権限リクエストを受理したら、その人数のアカウントをまず作成します。

useradd -g dev [user name]usermod -aG dev [user name]

アクセス制御ソリューションを利用すると、権限分離がさらに簡単ですが、Linux OSの機能を利用してユーザー別に権限を与えることができます。
2020年KISAが発表した「クラウド脆弱性点検ガイド」をご参考にして、セキュリティ設定を完了後、適切な権限を与えることで、運営者と開発者を分離することができます。

목차

ファイル権限の削除