【第14回】情報セキュリティの雪山(2) ~セキュアなアカウント管理~

 皆さま,こんにちは. 迷子のエンリュです.

 今回は,セキュリティを重視したアカウント管理を行っていきます.不要になったアカウントの削除,有効期限の設定,ログインシェルの管理などを主に扱います.よろしくお願いいたします.

 前回は,Linuxのセキュリティ強化の基本としてパスワードに関するセキュリティ強化を主に行いました.正しいアカウントの管理もまた,セキュリティを向上させる基本です.しっかり勉強していきましょう.

目次

不適切なアカウント管理がもたらす脅威

 近年では情報漏洩事件の話がちらほらと世間を騒がせています.情報化社会の到来とともに,私たちの身の回りのありとあらゆる情報が電子化され,ネットワーク上やクラウドで管理されるようになりました.また,ビッグデータ解析などの手法の確立によって情報がマーケティング業界などでも盛んに利用されるようになってきました.そんな時代ですから,情報漏洩がもたらす被害は,計り知れないほどになっています.

 情報漏洩事件のうちの多くは,実は内部からの不正アクセスによって引き起こされています.情報漏洩のほかにも,情報の改竄や破壊など,組織内部者の不正行為は数多く発生しています.その原因として,システムの管理体制が杜撰で,内部からの不正行為が容易である(IPA - 組織内部者の不正行為によるインシデント調査)ということが挙げられます.日本型組織は,協調を重んじ,他人を信頼しやすい日本人の気質の影響で,データへのアクセス権限の管理が曖昧であるとも言われています.そのため,欧米に比べて日本での組織内不正行為が多いのです.

 内部不正を未然に防ぐためには,「適切なアカウント管理」,「適切なアクセス権限」「操作ログの記録の徹底」などが必要です.「適切なアカウント管理」はシステムへのアクセスを制御することに通じます.実際に,退職者のアカウントが削除されずに残っており,それが犯罪に利用されてしまうといったケースもあります.

 システムを運用する前に,アカウントの管理方法についてしっかり定めておきましょう.

不要になったユーザーアカウント

削除する

 まずは不要になったユーザーアカウントを削除します.ユーザーの削除はuserdelコマンドによって行います.

$ sudo userdel -r USERNAME
# 削除するユーザが使用中の場合,fオプションで強制削除できます
$ sudo userdel -rf USERNAME

ロックする

 もしまたアカウントを使用する可能性がある場合でも,ログインできないようロックしておくことは必要です.アカウントのロックはpasswdコマンドで行うことができます.

$ sudo passwd -l USERNAME

 ロックを解除するときはuコマンドを使います.

$ sudo passwd -u USERNAME

管理者グループwheelから退会させる

 管理者交代など,アカウントは残したままだがアクセス権限を変えたいときは,グループから退会させることで制御できるようにするといいでしょう.ここではwheelグループが管理者権限を有するグループとして設定してありますので,前の管理者をグループから退会させることで管理者権限を返還させます.

$ sudo gpasswd -d USERNAME wheel

アカウントの有効期限

 あらかじめアカウントの有効期限を決めておくことも重要です.アカウントにはEXPIRE_DATEを設定でき,この日付を超えるとログインできなくなります.

既存のアカウント

# 既存のアカウントの有効期限はchage-Eまたはusermod-eで設定します.
# 日付はYYYY-MM-DDの形式か1970-1-1を0日目として数えた日数で指定します.
$ sudo chage -E YYYY-MM-DD USERNAME
または
$ sudo usermod -e YYYY-MM-DD USERNAME
# 確認はchage-lでできます.
$ sudo chage -l USERNAME

新規のアカウント

 アカウントを新規に作る際にオプションで有効期限を設定することができます.

$ sudo useradd USERNAME -e YYYY-MM-DD

 また,ユーザー作成時にオプションで指定されなかった値については,/etc/default/useraddに書かれたデフォルト値を使用します.デフォルト値は,直接ファイルを編集するかコマンドを介して変更することができます.

# -Dオプションのあとにオプションを続けることでデフォルト設定を変更します.
$ sudo useradd -D -e YYYY-MM-DD
# 確認は-Dオプション単独でできます.
$ sudo useradd -D
GROUP=100
HOME=/home
INACTIVE=-1
EXPIRE=yyyy-mm-dd    # 設定した値
SHELL=/bin/bash
SKEL=/etc/skel
CREATE_MAIL_SPOOL=yes

ログインシェルの管理

無効なシェルの設定

 ユーザーがログインしたとき,passwdファイルに書かれたログインシェルを使ってログインします./bin/bash, /bin/shなどが有効なログインシェルで,シェルが起動することでユーザーはシステムの操作を行うことができます.

 アカウントには,ログインを想定していないものもあります.ftpsshdなどのシステムアカウントがそれです.こうしたアカウントのログインシェルに有効なシェルが設定されてしまうと,それを介して不正ログインが行われる場合もあります.また,ログインを想定しないユーザーアカウントも,ログインシェルに無効なシェルを変更することでログインできなくすることができます.

 システムアカウントやログインを想定しないユーザーアカウントのログインシェルには,/bin/falseという無効なシェルを設定する必要があります.

# ログインシェルの確認はpasswdファイルでできます.
$ getent passwd enryu
enryu:x:500:500:Lost Enryu:/home/enryu:/bin/bash
↑一番末尾に記載されている/bin/bashがログインシェルになります

# 有効なシェルは/etc/shellsファイルで確認できます.chshコマンドを使います.
$ chsh -l
/bin/sh
/bin/bash
/sbin/nologin
    :
    
# 無効なシェルに変更します
$ sudo chsh /bin/false USERNAME
または
$ sudo usermod -s /bin/false USERNAME
# 新規ユーザーの場合
$ sudo useradd -s /bin/false USERNAME

falseとnologin

 /sbin/nologinというログインできないシェルもあります.これはログインはできませんが,正当なシェルになっているため起動することができます.正当なシェルとは/etc/shellsに定義されたもので,FTPでのログインができてしまいます.nologinは起動すると,ログイン試行のログを残してからメッセージを残してログインを拒否します.

 サイトによって言っていることはまちまちですが,システムアカウントには/bin/false,ログインを想定しないユーザーアカウントには/sbin/nologinを使うのがいいのかなと思います.

# /bin/falseへのログイン
$ su user
Password:
$        # パスワードを入力したのち,何も起こらず終了します


# /sbin/nologinへのログイン
$ su user
Password:
This account is currently not available.
$        # シェルは起動し,内部の処理でログインが拒否されます

システムアカウントのログインシェル

 CentOS6.8はデフォルトでシステムアカウントのログインシェルに/sbin/nologinが指定されています.パスワードがロックされているためログインはできませんから,このままでも問題はありませんが,このロックはroot権限で解除できますから,念のために上述の通り/bin/falseに変更します.まとめて変更する場合は直接/etc/passwdを変更する方が効率的でしょう.

$ sudo vi /etc/passwd

 :%s;/sbin/nologin;/bin/false/gcで確認しながらまとめて置換します.

パスワードの有効期限

 万が一パスワードが漏洩してもアカウントが不正利用されるリスクを減らすために,パスワードの有効期限を設定して,定期的にパスワードを変更させるようにしましょう.パスワードに関しては前回扱いましたのでここでは割愛します.

 今回扱うセキュアなアカウント管理方法は以上となりますが,実際には組織内でどのようにアカウントを運用していくか,誰がどれだけの権限でいつまで管理していくかなどのポリシーを定めておくことが大切です.刻々と変化する運用状況の中で,常にアカウントの管理について考えていくことを忘れないようにしましょう.

次回

 次回は,root権限の保護について扱っていきたいと思います.よろしくお願いいたします.

参考ページ

セキュリティ対策は急がず慌てず迅速に

 今回の内容はこちらの記事でも扱っています.

Previous Top Next
【第13回】 Journey 【第15回】
情報セキュリティの雪山(1) ~パスワードの強化~ Index 情報セキュリティの雪山(3) ~root権限の保護~