「みんなの翻訳」は、世界中の文書をみんなで協力して翻訳するサイトです。

みんなの翻訳ロゴ
ブクタブ
翻訳サイト

カテゴリ一覧

このサイトについて 新規登録はこちら お試し翻訳

一覧

2015/07/07

復旧のお知らせ

2015/06/08 ~ 2015/07/07 の期間、サーバ障害によりサービスが利用できない状況になっておりました。 現在は復…

List

Hnoss

English⇒Japanese

shikimi

English⇒Japanese

tkkobe

English⇒Japanese

K0hei22

English⇒Japanese

ホーム > 翻訳記事

翻訳記事

Dockerに新たなセキュリティ機能を導入する | from Opensouce.com / Daniel J Walsh

 2014年 9月 3日 Daniel J Walsh

  さて、Dockerセキュリティ解説第2部です。第1部では、Dockerユーザーが陥りがちな危険な誤解や心構えについて述べましたが、こんどはセキュリティを保つために具体的には何をすればよいかを紹介します。

  レッドハットのみならず、様々なオープンソース・コミュニティが共同で、Dockerの安全性を高めるために活動しています。
  セキュリティ対策がきちんとなされたコンテナを見ていると、ホスト側をだけでなく、コンテナも守れていることがわかります。
  Dockerで使えるセキュリティ対策は、主にレイヤード・セキュリティという、「セキュリティレベルをいくつかの段階に分けて、本当に大事なリソースやデータは確実に保護する」手法です。
 

  これはどんなものにも言えることですが、我々はシステムが破壊されないように、なるべくたくさんのセキュリティ・バリアを張っていきたいものですよね。
  それをコンテナに置き換えて考えてみましょう。たとえば、コンテナのなかにまったく区切りがなかった場合、最も大切な特権プロセスをすぐに乗っ取られてしまいます。我々はこれを何とか防ぎたいのです。
  Dockerには、Linuxで使用できるセキュリティ機能を、コンテナでもなるべく使おうとする機能があります。これを使っていきましょう。
 

  ここではRed Hat Enterprise Linux (RHEL) 7のセキュリティ機能を例にとって、Dockerコンテナの安全性を高める方法を見ていきます。

 

  ファイルシステムの防御

  ① 読み込み限定マウントポイント(=Read-only mount points)

  Linuxカーネルの中には、コンテナ環境の中にファイルシステムをマウントさせる方式のものがあります。ファイルの読み込みが素早く、プロセスの質が落ちないのが良い所です。
  さらに良いことに、これらのファイルシステムの大半が、「読み込み限定」としてマウントされます。なので、アプリケーションがファイルシステムを勝手に書き換えるということは、ほとんどありえないのです。

  Dockerの場合、以下のファイルシステムを「読み込み限定」としてマウントさせます。

. /sys
. /proc/sys
. /proc/sysrq-trigger
. /proc/irq
. /proc/bus

  これらのファイルシステムが読み込み限定でマウントされれば、コンテナの特権プロセスだろうとファイルを改変することはできません。つまり、ホストシステムに影響をきたすことはないということになります。
 もちろん、ファイルシステムを読み込み・書き込み(read/write)でリマウントしたとしても、コンテナの特権プロセスがファイルに与える影響を、ある程度制限することはできます。
 すべてのコンテナにおける、どんなファイルシステムにも、安全のための規制をかけることは可能です。これから、その具体的な方法をご説明します。
 

  ② コピーしたものになら、書き込み可能なファイルシステム(=Copy-on-write file systems)

  Dockerは、copy-on-writeファイルシステムを使えます。これは、ホスト側のファイルシステムのダミーを用意して、コンテナにホスト側とほとんど同じシステムを使わせる方法です。
 コンテナがダミーのファイルシステムにコンテンツを書き込んでも、コンテナからすれば、ファイルシステムに直接書き込んだも同じように動作します。

 こうすれば、そのコンテナに専用のファイルシステムを持たせることができるので、複数コンテナによるファイルシステム共用を防げます。複数のコンテナでファイルを共有すると、コンテナのうちのどれかがファイルを改変したことで、他のコンテナが誤作動を起こすリスクがあります。
 ここで大切なのは、たった1つのコンテナが行った変更が、他のコンテナの処理に影響をきたすことはない、ということです。

 

  実行権限の分類

  Linuxのセキュリティの質を上げる方法は、Linuxマンページでこう述べられています。:

  従来のUNIXでは実行権限をチェックするために、プロセスを2種類のユーザーに分離して考えました。
  1つ目は、特権を持ったプロセスで、これらは一般に、ユーザーID・0、あるいはroot、スーパーユーザーと呼ばれています。2つ目は、特権を与えられていないプロセスで、ユーザーIDには0でない数字が与えられます。
 特権ユーザーは、どんなカーネルを実行するにしても、すべての権限チェックが免除されています。
 それに比べて、権限を与えられていないユーザーは、一部カーネルにおいて、そのプロセスを実行する権限が与えられているかを確認せねばなりません。
 具体的には、「そのユーザーのIDに実行権限が与えられているか」、「そのユーザーが属しているグループのIDに実行権限が与えられているか」、「ユーザーが補助グループリストに該当しているか」を確認するのが一般的です。
 Linuxでもカーネル2.2で、このユーザーを明確に分類し、使用可能なカーネルに制限を与えられる機能が実装されました。これによりセキュリティの質が向上します。

  紹介した文章は、あくまでLinuxを指したものですが、Dockerアプリケーションにも同じ機能を適用することができます。むしろ、権限を与えるユーザーは限定しないと、アプリケーションを損壊される可能性が高まります。
  Dockerで使うことのある特権プロセスは、デフォルトでは次の通りです:chown, dac_override, fowner, kill, setgid, setuid, setpcap, net_bind_service, net_raw, sys_chroot, mknod, setfcap, audit_write

  これらを実行する際には、常に認証が伴います。Docker利用者は、Dockerを運用する際に使うコマンドラインから、認証が必要なプロセスのリストを変更することができます。

 

  権限認証の省略

  Dockerでは、次の操作において、権限認証の段階を省略しています。:

 CAP_SETPCAP

   プロセス・ケイパビリティを変更する

 CAP_SYS_MODULE

   カーネル・モジュールを追加、削除する

 CAP_SYS_RAWIO

   カーネル・メモリーを変更する

 CAP_SYS_PACCT

   プロセス・アカウントを設定する

 CAP_SYS_NICE

   プロセスの優先度を変更する

 CAP_SYS_RESOURCE

   リソース制限を無効化する

 CAP_SYS_TIME

   システム時計を修正する

 CAP_SYS_TTY_CONFIG

   ttyデバイスを設定する

 CAP_AUDIT_WRITE

   監査の記録(audit log)を記述する

 CAP_AUDIT_CONTROL

   監査サブシステム(Audit Subsystem)を設定する

 CAP_MAC_OVERRIDE

   Kernel MAC Policyを無視する

 CAP_MAC_ADMIN

   MAC Configurationを設定する

 CAP_SYSLOG

   Kernel printkの動作を制限する

 CAP_NET_ADMIN

   ネットワークを設定する

 CAP_SYS_ADMIN

   一覧を見る

  最後の2項目について、ここでもう少し説明しましょう。
 CAP_NET_ADMINの権限認証が省略されているのは、コンテナのプロセスが、システムのネットワークに手を加えられないようにしてあるからです。
 ネットワークは、コンテナ内部から修正・変更できないよういなっています。つまり、ネットワークデバイスに割り当てられたIPアドレスを変更したり、ルーティング・ルールを設定したり、iptablesを変更することができません。

  Dockerデーモンそのもののネットワーク設定は、コンテナを開始する前に済ませましょう。
 

  CAP_SYS_ADMINは、少し特殊なプロセスです。これを使うとカーネルに少し手を加えることができます。エンジニアが、新たな機能をカーネルに実装するときに、このプロセスはその機能に応じて適切な認証形式を与えられます。もちろん、既存のプロセスに新しい権限認証を作成することもできます。
 ただし、この機能は32ビットでしか使えません。開発側はあくまで、どうしてもカーネルに機能を追加しなくてはならない時に使用する、応急処置的なプロセスとして考えているのでしょう。
 CAP_SYS_ADMINで使用可能な機能は以下の通りです。
 (出典:/usr/include/linux/capability)
 

 セキュア・アテンションキーの設定

 乱数発生器の使用

 ディスク割当ての設定と、審査を行う

 ドメイン名設定

 ホスト名設定

 bdflush()の呼び出し

  mount()、umount()、新しくサーバー・メッセージブロックを作成する

 すべてではないが、autofsルートioctlsを使用すること

 nfsservctlの使用

  VM86_REQUEST_IRQの使用

 alpha上のpciコンフィングの読み/書き

 MIPS(setstacksize)上の irix_prctl の使用

 m68k (sys_cacheflush)状の全てのキャッシュを消去すること

 セマフォ削除

 セマフォと共用メモリの機能を持つ 、CAP_CHOWNの代替として、 "chown" IPCメッセージキューを使う

 共用メモリーセグメントのロック、ロック解除

 スワップのオン・オフ切り替え

 ソケット証明を通過したforged pidsの使用

 readaheadの設定と、ブロックデバイス上のバッファ消去

 フロッピードライバ内のジオメトリを設定する

 xdドライバー内への直接メモリアクセスの、オン・オフ切り替え

 mdデバイス(一部ioctlsにも対応)の管理

 不揮発性メモリデバイスへのアクセス

 apm_bios、serial、bttv (TV)デバイスの管理

 isdn CAPI対応ドライバのコマンド生成器の使用

 PCI 配置空間の変動割り当ての読み取り

 sbpcdドライバー上のDDIデバッグ入出力制御の使用

 シリアル・ポートのセットアップ

 raw qic-117コマンドの伝達

 SCSIコントローラー上のタグ付きキューイングの許可・禁止の切り替えと、任意でのSCSIコマンド伝達

 ループバック・ファイルシステム上の暗号キーを設定する

 zone reclaim policyの設定

 IDEドライバーの切り替え

  コンテナからCAP_SYS_ADMINを消すと、「Syscallのマウント」や「名前空間のモディファイ」というプロセスが阻止されてしまいます。そうなれば、ランダム・ファイルシステムのマウントや、読み込み限定ファイルシステムのリマウントがとうていできなくなります。つまり、ここで最も重要な機能は、この2つなのです。
 

 --cap-add --cap-drop

  Dockerには、権限認証を調節する機能があります。もし、ここでは権限の認証が必要とされないと思われるのなら、認証を取りやめることも可能です。
 たとえば、setuidとsetgidに権限認証が必要ない場合、次のように設定すれば、認証の手順を省略できます。

 docker run --cap-drop setuid --cap-drop setgid -ti rhel7 /bin/sh
 『--cap』の部分が、「capabilities」つまり、「権限認証」という意味です。
 setuidとsetgid以外には、すべてのプロセスに権限認証を持たせたい場合は、次のように設定します。
 

 docker run --cap-add all --cap-drop sys-admin -ti rhel7 /bin/sh
 『--cap-add all』では、sys-adminを除くすべてのプロセスに権限認証を付与させることができます。

 

  名前空間

  Dockerにも、名前空間を使用する機能があります。
 その中でも重要なものを2つ説明します。

  PID namespace

  PID namespaceを使うと、今コンテナがどのようなプロセスで動作しているかを、システムからしか確認できないようになります。プロセスが外部から覗かれないぶん、攻撃されづらくなります。コンテナの内側からstraceや ptraceを使っても、簡単にはプロセスを閲覧できません。
 「pid 1」で、この名前空間を停止させると、コンテナ内部のプロセスも自動停止します。これを利用すれば、必要な時にコンテナを停止させる操作ができるようになります。
 

  Network namespace

  Network namespaceも、セキュリティ対策には有効です。この名前空間で、ルーティング規則や、Iptablesなど、コンテナならではのネットワーク設定が可能です。
 これを使用すると、コンテナに3つのフィルターを持たせることができます。:

  •   1つ目は、インターネットと通信する時、
  •   2つ目は、プライベートなイントラネットで通信する時、
  •   3つ目は、他のコンテナと通信する時に仕掛けられます。


 3つ目のフィルターについてですが、コンテナ間でメッセージを中継して通信する時にも、不適切な通信を防御する役割を発揮します。

  cgroups

  サイバー攻撃の中には、サービスを妨害する目的のものもあります。
 手口としては、特定のプロセスやプロセス・グループを暴発させ、システム上のすべてのリソースを使い果たして、他のプロセスを一切受け付けられない状態にするものが多くを占めます。
 cgroupsを設定すると、Dockerコンテナが使用できるリソースの量に制限をかけられるので、いざこのような攻撃に遭っても被害が緩和できるようになります。

 たとえば、CPUにcgroup設定を行えば、攻撃の最中でもCPUにはまだ余裕がある可能性が残されます。なので、管理者がDockerを置いてあるシステムにログインして、CPUを管理しなおし動作を食い止めるチャンスが生まれるのです。
 新しいcgroupsには、コンテナがファイルを開きすぎたり、プロセスの個数が膨大になるなどして、リソースを圧迫した時に、どのような対応を取るかを設定する項目が追加されました。
 cgroupsをより上手に使えば、Dockerのセキュリティをさらに高めることができるでしょう。
 

  デバイスcgroups

  さらにDockerの場合、コンテナ内で使われるデバイスノードに対して、特殊なcgroupsを与えることが可能です。これを設定することで、余計なプロセスを削減し、ホストへの攻撃になり得るデバイスノードの使い方を阻止することができます。

  デバイスノードには、カーネルの設定を変更する力があります。デバイスノードを乗っ取られると、ホストシステムをごと操作され、危険です。
 

  デフォルトでは、コンテナ内に作成されるデバイスノードに以下のような名前が付けられています。

 /dev/console、 /dev/null、 /dev/zero、 /dev/full、 /dev/tty*、 /dev/urandom、 /dev/random、 /dev/fuse
 Dockerイメージは、nodevでマウントさせることも可能です。これを使えば、デバイスノードが書き換えられたとしても、コンテナの中のプロセスがカーネルと関わりを持つことはありません。

 注:デバイスノードを作成すると、同時にCAP_MKNOD の権限認証が削除されることになります。Docker側でこれを回避するには、あらかじめデバイスノードの動作に制限を設ける必要があります。
 個人的には、将来、コマンドラインで--optオプションを入力するだけで、権限認証の省略が行えるようになれば良いなと思っています。

 

  AppArmor

  ApparmorをDockerコンテナに適用させることは可能です。ただ、現在私が使っている、RHELとFedoraでは、AppArmorに対応していません。それで自分はちょっとこの辺には詳しくないので、はっきりとしたことは申し上げられません。気になる方は各自で調べておいてください。
 (その代わり、SELinuxの使い方を詳しく説明していきます。)

 

  SELinux

  まずは、SElinuxについて大まかに説明しましょう。:

  • SELinuxは、ラベリングシステムである
  • 全てのプロセスには、ラベルがつけられる
  • どんなファイル、ディレクトリ、システム・オブジェクトにもラベルがつけられる
  • ラベルがつけられれたプロセスとオブジェクト間のアクセスを操作にするには、ポリシールールを変更する必要がある
  • カーネルでルール付けができる

 SELinuxを使うと、強制アクセス制御システムを実装できます。これは、誰かが1つのオブジェクトの所有権を持ったところで、それ以上の権限は持たせない仕組みです。これにより、他のオブジェクトにアクセスしたり、オブジェクトを勝手に操作されることが防止できます。このシステムは、カーネルで実行されます。
 以前私は、SELinuxの動作の仕組みを図で説明したことがあるので、(のちにそれを『SELinuxぬりえ』としてまとめたのですが、)それを使って、
 

  「SELinuxをDockerコンテナのプロセス管理に有効活用する方法」を2つご紹介します。
 

  ①Type enforcement

  図1
 Type Enforcementには、コンテナ内部で起こったプロセスからホストシステムを防御する効果があります。

  Dockerコンテナを運用していると、「svirt_lxc_net_t」というラベルがデフォルトで適用されていますが、それにはこのタイプの防御法を実行する機能がついています。

  コンテナ内部のコンテンツには、全て「svirt_sandbox_file_t」というラベルが張られています。

 それらコンテンツを管理することが許可されたファイルには、「svirt_lxc_net_t」というラベルがつけられます。これらはホスト側の/usrディレクトリに保管され、その大半が読み取り/実行可能ファイルです。

  しかし、このラベルがついたファイルは、他のラベルが付いたコンテンツを開いたり、書き込んだりすることができません。デフォルトの設定では、/var、/root、/homeなどのディレクトリの読み取りすら禁止されています。

  プロセスに必要な工程は、基本的に「読み取り/実行」です。システムの「データ」に触れる必要はあまりない上に、リスクだけは高まります。なので、デフォルトではシステムのデータには触らないように設定されているのです。
 

  欠点

  ここで1つ問題があります。先ほど、「svirt_lxc_net_t」は「svirt_sandbox_file_t」のラベルが付いたコンテンツしか動かせないと述べましたが、裏を返せば「そのラベルがついたコンテンツなら、他のコンテナのものでも操作して構わない」と、機械に認識させてしまうのです。
 同じマシンで複数のコンテナを連立させる場合、この対策がかえって仇(あだ)となります。

 

  もう少し詳しく

  先ほど紹介したラベルの中に、「net」という語句が登場しましたね。ラベルに「net」が記載されているコンテンツには、ネットワークをフル活用することが許可されています。しかし、これはあくまで、デフォルトの設定です。
 もちろん、これを変更して動きに制限をかけることもできます。次のような手順を踏みます。

 docker run -ti --security-opt label:type:lxc_nonet_t rhel7 /bin/sh

  この設定で、コンテナ内のプロセスに一切のネットワーク・ポートの使用を禁止させることができます。
 同じような設定が、Apacheポリシーにもありますが、こちらはコンテナにApacheポートの接続のみを許可し、インターネット・ポートそのものには触れさせない対応を取っています。
 このタイプの対策を取ると、コンテナに脆弱性があったとしてもスパムボット化したり、ハッキングでコンテナ内のapacheプロセスを乗っ取られたりすることを防げます。

 

  ②Multi Category Security enforcement

  図2
 Multi Category Security (MCS)は1つのコンテナが他のコンテナから操作を受けることを予防します。なので、こちらが複数のコンテナを運用する上で重要な対策になります。

  Multi Category Securityは、Multi Level Security (MLS)が基本となっています。MCSは、SELinuxにおけるMLSの分野で最も新しく搭載された機能で、コンテナ同士の干渉を防止する機能がついています。
 コンテナがDockerデーモンに導入されると、DockerはMCSラベルをランダムに貼り付け(例: s0:c1, c2, )、コンテナを識別します。同じように、コンテナ内のコンテンツにもMCSラベルを張り付けます。
 こうすることで、プロセスと、ファイルシステム・コンテンツのMCSラベルが一致しているときにだけ、カーネルが呼び出され、コンテンツの読み取り/変更が慎重に行われるようになるのです。
 MCSラベルが異なれば、カーネルがそのコンテナのプロセスを阻止して、読み取り/変更は行われません。
 

  1つのコンテナのプロセスを乗っ取り、他のコンテナまでもを動かすというのがハッカーの常套手段ですが、Dockerは必ずやコンテナごとに異なるMCSラベルを付けるので、少し安心です。
 以前私が制作したこちらのビデオには、この対策を取ったOpenShiftコンテナが、root権を取られたとして、どのような動きを見せるのかが紹介されています。Dockerコンテナでもこれと同じような対策が取れますので、ぜひ参考にしてください。

  
 上のような対策を打つために、私はSELinuxコンテンツをきちんと指定して導入しています。管理者権限でログインして、以下のように指令しました。

 docker run --ti --rm --label-opt level:TopSecret rhel7 /bin/sh

  これでMulti Level Security (MLS)環境が整った状態で、コンテナを開始できます。もちろん、MLSが必要とされる機能も使えるようになりますよ。

 

  SELinuxの問題点

  ファイルシステムへの対応

  通常、SELinuxはデバイス・マッパー・バックエンドのみで動作します。BTFSでは動作しませんし、BTRFSでのコンテンツのマウントやラベリングにも対応していません。これらのファイルシステムは、コンテナを開始してmountコマンドを入力しても、コンテンツにラベルが張られないので動作できません。これを解決するには、エンジニアによる努力と、コンテナにマージするためのOverlayfsの可能性にかけることが求められます。
 

  ボリュームのマウント

  Type Enforcementでは、コンテナのプロセスにsvirt_sandbox_file_tラベルの付いたコンテンツの読み込み/変更を許容していたものの、ボリュームのマウントという問題が残っています。
 この際のボリュームのマウントとは、コンテナにディレクトリのまとまりをマウントさせる、たったそれだけのことなのです。でも、それがラベルがついていないという理由だけで阻害されてしまいます。
 ボリュームにあるコンテンツに、コンテナのプロセスが読み込み/変更ができるようにすためには、コンテンツにsvirt_sandbox_file_tラベルを付けなくてはなりません。たとえば、以下のように。
 

Volume mounts /var/lib/myapp
chcon -Rt svirt_sandbox_file_t /var/lib/myapp

  なので、私はこれらのラベルを自動的に付与させるパッチを記述しました。このパッチをDockerに適用すると、マウントしたボリュームにラベルが付くだけでなく、プライベートラベル「Z」か、シェアラベル「z」が自動的につけられます。

docker run -v /var/lib/myapp:/var/lib/myapp:Z ...
docker run -v /var/lib/myapp:/var/lib/myapp:z ...


 うまくいけば、マージがスムーズに実行されるようになります。


 

  統括

  ここまで、Dockerコンテナを素のままの状態よりもより安全に管理する方法を伝えてきましたが、これらはあくまでテクニックに過ぎません。よりよい方法が現れれば、そちらに変わっていくまでです。
 ですが、第1部で述べたような基本的な内容は、基本だからこそ、いつだって人々につきまとうのです。

  •  信頼できる開発元のソースしか使わない
  • アプリケーションは、企業が使ってもおかしくないクオリティのホストで運用すること
  • パフォーマンスのために、不必要な特権認証をなくすこと
  • ソフトは常に最新にアップデートすること
  • ログを確認すること
  • 「stenforce」は1
     
 さらに進んだDockerセキュリティ対策においては、私の次回の記事にします。ここまで、読んでくれてありがとうございました。

 

PDF
更新日:2017-06-28 20:57:55 Hnoss 0  del.icio.usに追加   はてなブックマークに追加   twitterに投稿   facebookでshare
[ 原文 ] https://opensource.com/business/14/9/security-for-docker Creative Commons License この作品は、クリエイティブ・コモンズ・ライセンスの下でライセンスされています。
クリエイティブ・コモンズ・ライセンス
翻訳者ページをみる

この記事の翻訳者

Hnoss さんの翻訳記事

オープンソース・ホームオートメーションシステム5選 | from Opensource.com

  「 ユビキタス・ネットワーク(Internet of Things) 」と聞いても、みなさんピンとこないでしょう。ですが、それを実生活に取り入れることは、だんだんと簡単になってきています。た…2017-07-19 15:08:40

実際このように使う。Linux検索コマンド35選 | from Tecmint.com

 検索コマンドはLinuxシステムを管理する上でかなり重要な、使用頻度も高いコマンドだ。検索コマンドは文字通りファイルを「検索」するだけでなく、ファイルやディレクトリのリストを探…2017-07-16 18:02:39

オープンソースな「マーケティング・スタック」を7つ紹介 | from Opensouce.com

 マーケティングで便利なオープンソースソフトウェアを紹介します。人によっては、プロプライエタリ・ソフトである必要がなくなるかもしれません。 2017年6月28日 |  Thomas Carn…2017-07-14 12:56:07

ラズパイを電子書籍サーバーにする方法があります! | from Opensource.com

 Calibreという電子書籍管理ソフトウェアがありますが、セットアップの方法次第では、Raspberry Pi3を電子書籍サーバーに変身させられます。  ちょっと意外な気がするかもしれません…2017-07-14 12:55:02