対象読者

これは、プロジェクトのITインフラへのアクセスや管理でLinux ワークステーションを使用しているシステム管理者向けの資料です。

システム管理者が遠隔から管理をしている場合は、ワークステーションが主要なセキュリティ条件を満たしていることを確認することで、ITインフラ全体へのサイバー攻撃の進入経路となることを防ぐことができます。その際、ここに書いたガイドラインを参考にしてください。

システム管理者が遠く離れた場所にいない場合でも、携帯可能なノートパソコンを使用している可能性や緊急対応用に自宅から会社のネットワークにアクセスできるよう設定している可能性があります。いずれの場合でも、環境に合ったガイドラインの適用をお勧めします。

制約事項

これは、「ワークステーションの強化」を徹底した資料とは言えません。しかし、これが明白なセキュリティ上のエラーを起こすのを回避できる基本的ガイドとなればと思います。面倒な手順は増やさないようにしたいと思います。この資料を読んで考え過ぎと思う人もいれば、まだまだ考えが甘いと思う人がいると思います。セキュリティは、高速道路を運転するようなものだと思います。自分より速度の遅い車に対してはイライラし、速度の速い車にはハラハラするものです。このガイドラインはあくまで基本的な安全規則であり、完璧でもありませんし、経験や警戒、常識などに取って代わるものでもありません。

ITポリシーの文書化に役立つ、オープンソースの共同開発で得た情報 を共有するため、この資料を公開しています。

構成

各セクションを2つの分野に分けています。

• プロジェクト内容に合わせて適用できるチェックリスト
• その事項をリストに加えるに至った経緯を説明する自由形式の検討事項リスト

チェックリストの優先順位

チェックリストの項目に優先順位を付けていますので、必要の有無を決める際に参考にしてください。

• (必須)検討事項リストの上位にあるべきもの。実装されていない場合、ワークステーションのセキュリティを脅かす可能性がある。
• (好ましい)セキュリティ全体を向上するもの。しかし実装した場合、作業環境に影響する可能性がある。そのため、新しい知識や習慣を学ぶ必要、古い知識や習慣を捨てる必要が出てくる。
• (こだわり)ワークステーションのセキュリティを劇的に向上するもの。しかし、OSの操作に影響するため、大幅な調整が必要になる可能性がある。

これはあくまでもガイドラインであること覚えておいてください。もし、この優先順位が関わっているプロジェクトのセキュリティ条件を満たしていないと思う場合は、条件に合うよう調整をしてください。

適切なハードウェア選び

ここでは、特定のメーカーやモデルを推奨するつもりはありません。このセクションでは、コンピュータを選ぶ際に考慮すべきことについて述べます。

チェックリスト

• コンピュータはセキュアブートをサポートしている。 （必須）
• コンピュータにFirewireやThunderbolt、ExpressCardポートがない。 （好ましい）
• コンピュータにセキュリティチップ(TPM)がある。 （こだわり）

検討事項

セキュアブート

賛否はあるものの、セキュアブートは手間をかけずにワークステーションを狙った攻撃（ルートキットや”Evil Maid”等）を防ぐことができます。本格的な集中攻撃を阻止はすることはできません。また、国家レベルのセキュリティ機関であれば、セキュアブートを使用しなくてもそのような攻撃を阻止する対策（おそらく設計）が施されているでしょう。しかし、何もないよりセキュアブートがあった方が良いのです。

代わりに Anti Evil Maid を設定しても、セキュアブートで阻止できるタイプの攻撃から包括的に守ることができます。しかし、設定や維持は簡単ではありません。

Firewire、Thunderbolt、ExpressCardポート

Firewireは標準規格で、設計上、接続すればどのデバイスでもコンピュータのメモリに直接アクセスできるようになっています。( ウィキペディアを参照ください )。ThunderboltとExpressCardも同じですが、後にThunderboltでは、メモリへのアクセスを限定しています。使用するコンピュータにこれらのポートがないのがベストですが、大抵の場合UEFIを使用してポートを無効にできるため、重要ではありません。

セキュリティチップ（TPM）

セキュリティチップ（TPM：Trusted Platform Module）は、プロセッサとは別にコンピュータのマザーボード上に取り付けられた暗号チップで、プラットフォームのセキュリティを強化するためにも使用できます（例えば、HDDの暗号化キーをセキュリティチップが格納・管理します）。しかし、これは日常的な作業で使用されるものではありません。セキュリティチップは、特定の目的がない限り、ワークステーションのセキュリティ上必要とは言えません。

OS起動前の環境

ここでは、OSをインストールする前にしておいた方が良いことについて述べます。

チェックリスト

• UEFIモードで起動する（従来のBIOS互換モードではなく） *(必須)
• UEFIの設定をするためのパスワードを設定する。 *(必須)
• セキュアブートを有効にする。 *(必須)
• システムを起動するためのUEFIレベルのパスワードを設定する。 (好ましい)

検討事項

UEFIとセキュアブート

欠点はあるものの、セキュアブートのように、UEFIには従来のBIOSでは提供せれていないたくさんの良い技術があります。最近のコンピュータの多くはUEFIモードがデフォルトで設定されています。

UEFI設定モードのパスワードには強固なものを設定してください。メーカーはパスワードの文字数制限も設けている場合が多いので、長いパスフレーズではなく、短く無作為な文字列のパスワードを作成する必要があります（後でさらにパスフレーズについて述べます）。

使用されるLinuxディストリビューションによって異なりますが、ディストリビューションの起動を可能にするセキュアブートキーをインポートする手順が増える場合があります。多くのディストリビューションはMicrosoftと提携しているため、リリースしているカーネルを、ほとんどのメーカーが既に認証しているキーで署名しています。この場合、新たにキーをインポートする手間はありません。

特別な措置としてブートパーティションにたどり着くには、パスワードの入力が必要になるよう設定をしましょう。のぞき見されても大丈夫なようにUEFI管理パスワードとは違うパスワードにしてください。しかし、頻繁にコンピュータの電源を落としたり立ち上げたりする場合は、すでにLUKSパスフレーズを入力しなければならないので、必要はないでしょう。

ディストリビューション選び

使用されるのは、広く使用されている、Fedora、Ubuntu、Arch、Debian、あるいはこれらから派生したバージョンかもしれません。いずれにせよ、ディストリビューションを選ぶ際に参考にしてください。

チェックリスト

• 堅固なアクセス制御システムMACやRBACが導入されている （SELinux/AppArmor/GrSecurity）。 (必須)
• セキュリティ情報を公開している。 (必須)
• 適時セキュリティ情報を更新している。 (必須)
• 暗号化署名の検証を導入しているパッケージを提供している。 (必須)
• UEFIとセキュアブートがサポートしている。 (必須)
• 堅固かつネイティブなフルディスク暗号化機能をサポートしている。 (必須)

検討事項

SELinux、AppArmor、GrSecurity/PaX

強制アクセス制御（MAC：Mandatory Access Controls）とロールベースアクセス制御（RBAC：Role-Based Access Controls）は、過去の遺物と言われるPOSIXシステムで使用されていた、基本的なユーザ・グループベースのセキュリティ構造に基づいています。多くのディストリビューションにはすでにMACやRBACが搭載されている（FedoraやUbuntu）か、オプションとして、後から導入できるようになっています（GentooやArch、Debian）。MACやRBACが設定されているディストリビューションを選ぶことをお勧めします。しかし、デフォルトで搭載されていない場合は、インストール後、別途アクセス制御を設定してください。

MACやRBACが提供されていないディストリビューションは極力避けた方が良いと思います。伝統的なPOSIXユーザやグループベースのセキュリティにとっては、今日の状況になくてはならないと考えます。MACやRBACのワークステーションを使用したい場合、一般的に、SELinuxよりもAppArmorやGrSecurity/PaXから始めた方が覚えられやすいと思います。ワークステーションには、外部からのリスニングデーモンがほとんど、またはまったくありません。また、ユーザの実行するアプリケーションがワークステーションに最も高い危険性をもたらす可能性があります。これらのことから、SELinuxだけよりもAppArmorやGrSecurity/PaXの方が、セキュリティ上のメリットがあります。

ディストリビューションに関するセキュリティ情報

広く使われているディストリビューションならば、その多くは公開されたセキュリティ情報をユーザに配信するメカニズムを備えています。もし皆さんが物事を秘密裏に進めたい場合には、開発者側がセキュリティの脆弱性やパッチに関する警告を文書で示しているかどうか、確認してみましょう。そのような仕組みを有していないディストリビューションならば、それはメインの管理ワークステーションとしては十分ではない、ということを意味します。

タイムリーかつ信頼のおけるセキュリティ情報の更新

広く使われているディストリビューションならば、その多くはセキュリティ情報の更新を定期的にユーザに配信しています。こうした重要なパッケージ更新情報が、タイムリーに提供されているかどうか、念には念を入れてしっかり確認しておきましょう。そういう意味では、スピンオフや「Community rebuilds」といった類のものは使わない方が良いです。これらを用いると、情報が上流側からまず公開されるのを待たなくてはならないので、セキュリティ情報の更新にも常に遅れが生じてしまいます。

パッケージ、メタデータの更新情報、あるいは両方ともについて、ディストリビューションは暗号化署名を利用しています。対応していないディストリビューションを見つけるのはなかなか大変でしょう。とはいえ、この基本的なセキュリティ対策を導入しないまま、今まで何年もの間、良く使われてきてしまったディストリビューションもあります（Archの例を思い出してみましょう）。確認するべきポイントの1つです。

UEFIとセキュアブートをサポートしているディストリビューション

ディストリビューションがUEFIとセキュアブートをサポートしているかどうかも確認する必要があります。エクストラキーのインポートを要求しているかどうか気を付けましょう。また、（Microsoftと合意済み、等の条件で）システムメーカーによってあらかじめ認証されたキーを使って起動カーネルが認証されているかどうかも確認しましょう。ディストリビューションの中には、例えUEFIやセキュアブートをサポートしていなくても、改ざんが防止されていること、もしくは改ざんが加えられた場合にはそのことを明白に起動環境で示す代替手段を使っているものもあります（先ほど紹介したAnti Evil Maidを使っている Qubes-OS 等のことです）。万が一ディストリビューションがセキュアブートをサポートしておらず、起動レベルでの攻撃を防ぐ仕組みを何も有していない場合には、他のディストリビューションを当たりましょう。

フルディスク暗号化の可否

フルディスクの暗号化は、休止状態時にデータを安全に保つために必要な要件で、ほとんどのディストリビューションでサポートされています。代替方法として、自己暗号化されたハードドライブを使ったシステムが使われることもあります。（通常、ホード上のセキュリティチップ（TPM）を介して実装されています）。このシステムは、フルディスクの暗号化に匹敵するレベルのセキュリティ策を実現する同時に、より高速なオペレーションも可能としますが、コストも相当に高くつきます。

ディストリビューションのインストールに関するガイドライン

ディストリビューションによって異なりますが、共通するガイドラインは次のとおりです。

チェックリスト

• 堅固なパスフレーズでフルディスクの暗号化（LUKS）を利用している。 （必須）
• スワップも確実に暗号化されている。 （必須）
• ブートローダを編集するためにもパスワードを必要とする（LUKSと同じパスワードでも可能）。 （必須）
• 堅固なルート用パスワードを設定する。（LUKSと同じパスワードでも可能）。 （必須）
• 管理者グループに属し、特権は持たないアカウントを利用する。 （必須）
• ルート用パスワードとは異なる、より堅固なユーザアカウント用パスワードを設定する。 （必須）

検討事項

フルディスクの暗号化

自己暗号化されたハードドライブを利用していない限り、データやシステムファイルを保存するディスクを全て、完全に暗号化するようインストーラに設定することが重要になります。自動的に搭載される暗号化論理デバイスであるループファイルを使った、簡単なユーザディレクトリの暗号化だけでは十分とは言えません（昔のUbuntuのようなケースです）。なぜなら、こういったシンプルな暗号化では、センシティブなデータをたくさん有しているかもしれないシステムのバイナリやスワップを一切保護できないからです。代わりに、LVMデバイスを暗号化する方法をお勧めします。起動プロセス中にたった1つのパスフレーズが必要になるだけで実装可能です。

ブートローダは、暗号化されたLUKS/dmが呼び出される前にカーネル自体を起動させる必要があります。従って、 /boot パーティションは通常暗号化されずに残されます。しかし中には、 /boot パーティションの暗号化もサポートするディストリビューションもあります（ Arch 等）。他のディストリビューションでも同じことはできますが、複雑なシステムアップグレードがおそらく必要となるでしょう。もし選択したディストリビューションがもともと /boot パーティションの暗号化をサポートしていないのであれば、そこにそんなにこだわる必要はありません。カーネルのイメージ自体は何らプライベートデータを漏えいしませんし、また改ざん防止については、セキュアブートによって暗号化署名の検証が導入されています。

堅固なパスフレーズの選び方

最近のLinuxシステムでは、パスワード/パスフレーズの長さに制限はありません。
実際の長さは、皆さんがどれだけこだわって意地になるかにかかっています。システムを何度も起動する場合を考えてみましょう。少なくともそれぞれ2つのパスワードをタイプする必要があります。1つはLUKSの暗号を解除するため、もう1つはログインするためです。ですから、万が一長いパスフレーズを使っていた場合には、すぐに疲れてしまうでしょう。パスフレーズを作成する際にはたくさんの語数にあたり、組み合わせても意味がない、でもタイプしやすい単語を2つか3つ選びましょう。

堅固なパスフレーズの例です（スペースも利用できます）。

• nature abhors roombas
• 12 in-flight Jebediahs
• perdon, tengo flatulence

解読されやすいパスフレーズは、公開されている作品や実際の生活のどこかでよく目にする言葉の組み合わせです。例えば次のようなものです。

• Mary had a little lamb
• you’re a wizard, Harry
• to infinity and beyond

パスフレーズの中で、言葉にはなっていない、少なくとも10から12文字の長さのパスワードを使い続けることも可能です。

物理的なセキュリティ問題が気にならないのであれば、パスフレーズを書きとめて、作業デスク以外の安全な場所に保管しておいてもかまいません。

ルート及びユーザのパスワード、そして管理グループ

ルートパスワードには、LUKSの暗号化に使ったものと同じパスワードを設定することをお勧めします。（ただし、コンピュータを信用できる第三者とのみ共有する場合に限ります。第三者とは、ドライブを解除することはできてもルートの権限を持つことはできない人のことです）。コンピュータを完全に自分だけで使う場合、LUKSのパスワードと違うルートパスワードを持っても、セキュリティ上は何も意味がありません。UEFIの管理、ディスクの暗号化、そしてルートアカウントについては、一般的には同じパスワードを使っても問題ありません。このうちのどれか1つでもパスワードが漏えいしたら、結局は攻撃者が完全にシステムをコントロールできてしまいます。ですから単一ユーザによるワークステーションにとっては、異なるパスワードを使い分けたとしても、セキュリティ上の対策にはほとんどなりません。

しかし、通常のタスクを実行する一般のユーザアカウントに対しては、それぞれ異なる、どれも堅固なパスワードを設定する必要があります。こういったユーザは、管理グループのメンバーでなければなりません（ディストリビューションによって異なりますが、 wheel もしくは同様の形式）。このアカウントを使えば、特権を更に高めることができる sudo を実行することが可能になります。

つまり、ワークステーションを完全に自分だけで使う場合には、2つの異なる確かな、それぞれ堅固であるパスフレーズを必ず設定する必要があります。その際には、次のことを頭に留めておきましょう。

管理レベルとは、次のような場面で利用されるものを指します。

• UEFIの管理
• ブートローダ（GRUB）
• ディスクの暗号化（LUKS）
• ワークステーションの管理（ルートユーザ）

ユーザレベルとは、次のようなものを指します。

• sudoを実行できるユーザアカウント
• パスワード管理者にとってのマスターパスワード

やむを得ない状況によってはもちろん、全て違うパスワードを設定することも可能です。

インストール後の強化

インストール後のセキュリティの強化は、あなたのディストリビューションの選択に拠るところが大きいです。ですから、この記事のような一般的な文書で詳細なやり方の説明をしてもあまり意味がありません。それでも、やるべきいくつかのステップの例を以下に挙げておきます。

チェックリスト

• FireWireとThunderBoltモジュールをグローバルに無効にする （必須）
• 全てのインカミングポートにフィルタがかかっているかファイアウォールを確認する （必須）
• ルートメールが、あなたがチェックするアカウントに転送されるか確認する （必須）
• 自動でOSの自動更新のスケジュールやリマインダを設定する （必須）
• sshdサービスがデフォルトで無効になっているか確認する （好ましい）
• しばらく操作がない時、クリーンセーバが自動でロックするように設定する （好ましい）
• Logwatchを設定する （好ましい）
• rkhunterをインストールして使う （好ましい）
• 侵入検知システムをインストールする （好ましい）

検討事項

モジュールのブラックリスト化

FireWireとThunderBoltモジュールをブラックリスト化するには、 /etc/modprobe.d/blacklist-dma.conf のファイルに以下の行を追加してください。

blacklist firewire-core
blacklist thunderbolt

モジュールは再起動時にブラックリスト化されます。これらのポートがなくても、ブラックリスト化に影響はありません（しかし、何もしない、とも言えますが）。

ルートメール

デフォルトでは、ルートメールはただ単にシステムに保存されるだけで、読まれることはほとんどありません。 /etc/aliases であなたが実際に読むメールボックスにルートメールが送られるように設定してください。でないと、重要なシステムの通知や報告を見逃してしまうかもしれません。

# Person who should get root's mail
root:          bob@example.com

この編集をしたら、 newaliases を実行して確実に送信されているか確認してください。存在しないかもしくはルーティング可能でないドメンインネームから来たEメールを拒否するEメールプロバイダもあるからです。このような場合、実際に送信できるようになるまでメールの転送設定をする必要があります。

ファイアウォールとsshdとリスニング・デーモン

デフォルトのファイアウォールの設定は、ディストリビューションに拠ります。しかし多くは、 sshd のインカミングポートを許可します。インカミングsshを許可するような、やむを得ない合理的な理由がない限り、フィルタをかけて sshd デーモンを無効にしましょう。

systemctl disable sshd.service
systemctl stop sshd.service

もし必要であれば、一時的に使うのもいいでしょう。

一般的に、システムではpingの応答とリスニングポートを一緒にすべきです。そうすれば、ネットワークレベルのゼロデイ・エクスプロイトに対して対策ができます。

自動更新、もしくは自動通知

自動更新すると、システムが使用できなくなってしまうかもしれないという恐怖（しかしこれは過去の出来事ですので心配はいりません）などの特別な理由がない限り、自動更新を設定しておくことをお勧めします。少なくとも、更新ができる状態になった時の自動通知を設定しておくのがいいでしょう。ほとんどのディストリビューションは、自動的にこのサービスを実行していることが多いでしょうから、基本的には設定をいじる必要はありません。詳細はそれぞれの付属資料を読んでください。

特に”セキュリティ更新”と記載がなかったり、CVEコードと関係していなくても、可能な限り早く、全ての素晴らしいエラッタを適用してください。全てのバグはセキュリティバグになりかねませんし、より新しく知られていないバグが発生してしまってもそのほうが、古いバグよりも安全なことが多いです。

ログを見る

システム上で何が起きているのかということに強い興味があるはずですよね。それなら、 logwatch をインストールし、夜間にシステム上で起こったこと全てのレポートを送信するように設定してください。熱心な攻撃者を防ぐことはできませんが、いいセーフティネットを整えることはできます。

多くのsystemdディストロは、今では logwatch で必要なsyslogサーバを自動的にインストールしなくなりました（systemdが自身のジャーナルを頼りにするからです）。ですから rsyslog をインストールして有効にし、logwatchを使う際に /var/log が空っぽでないことを確認しておきましょう

Rkhunterと侵入検知システム

aide や tripwire のように rkhunter と侵入検知システム（IDS）をインストールしてもその機能やセットアップの正しい手順（例えば、外部メディアにデータベースを置くとか、信頼性ある環境から確認をするとか、ハッシュデータベースを再読み込みはシステムの更新が行われたり設定が変わったりした後にするなど）を踏まなければあまり役には立ちません。これらの段階を踏まなかったり、自身のワークステーションでのやり方を調整しなければ、これらのツールは明らかなセキュリティ上の利点も生み出すこともなく、イライラさせられるだけでしょう。

rkhunter のインストールと実行は、夜に行うことをお勧めします。そして、 rkhunter は使い方を学ぶのも、実際に使うのもとても簡単です。巧妙な攻撃者を防止することはできませんが、ミスを発見する手助けにはなるはずです。

個人のワークステーションのバックアップ

ワークステーションのバックアップは軽視され、大雑把に行われることが多いようです。でもこれでは安全とは言えません。

チェックリスト

• 外部ストレージに暗号化されたワークステーションのバックアップを設定する （必須）
• オフサイトバックアップもしくはクラウドバックアップのために、ゼロ知識バックアップツールを使う （好ましい）

検討事項

外部ストレージへの完全に暗号化されたバックアップ

全てのバックアップを保存できる外部ハードドライブを使うと、通信速度や上りの速度のようなことを気にしなくて済むので便利です（最近でも、ほとんどのプロバイダで、まだアップロード/ダウンロードの速度が著しく非対称です）。言うまでもありませんが、このハードドライブ自体を（LUKSで）暗号化するか、暗号化されたバックアップを作成できる duplicity やGUIの仲間の deja-dup のようなバックアップツールを使ってください。私のお勧めは、安全なオフラインの場所にうまい具合にランダムに作成したパスフレーズを保存できる後者のほうです。もしラップトップを持ち歩く場合は、このドライブは自宅に残していけば、万が一ラップトップを紛失したり盗まれたりしても安心です。

ホームディレクトリに加えて、さまざまな犯罪対策として、 /etc や /var/log のバックアップも取っておいたほうがいいでしょう。

ということで、システム間のファイルの移動が速いとしても、暗号化されてないストレージにホームディレクトリをコピーするのはやめましょう。作業が終わってしまえば、削除するのを忘れてしまう人がほとんどです。そうなれば、プライベートな情報が流失したり、犯罪者が機密性の高いデータが手に入れてしまうことになります。特に、そのストレージメディアをラップトップと同じカバンに入れるのは一番危険な行為です。

精選されたオフサイトのゼロ知識バックアップ

オフサイトバックアップもとても重要です。オフサイトバックアップは、もしスペースが許せば会社に、もしくはクラウドプロバイダに対して実行されます。オフサイトでバックアップする必要のない膨大なデータ（インターネットキャッシュ、音楽、ダウンロードなど）を移動させないために、duplicity/deja-dupのプロファイルを別々に設定して、最も重要なファイルだけを対象としましょう。

他にも、 SpiderOak のようなゼロ知識バックアップツールが使えます。SpiderOakは素晴らしいLinux GUIツールを提供し、複数のシステムやプラットフォームの中でコンテンツを同期できるような、便利な特徴もあります。

ベストプラクティス

下記にリスト化したのは、皆さんが活用すべき思われる選りすぐりのベストプラクティスです。完全に網羅はされていませんが、セキュリティと全体的な使い勝手のバランスをうまく保つ、実践的なヒントがあるはずです。

ブラウジング

Webブラウザが、システムの中でも最も攻撃にさらされやすいソフトウェアだということに異論はないでしょう。Webブラウザは、信頼性がなく、敵意さえあるかもしれないコードをダウンロードして実行するために特に記述されたツールです。サンドボックスやコードのサニタイゼーションのようなさまざまな方法を使用することで、あなたを危険から守ろうとしてくれます。しかし、それらの方法は全て、さまざまな環境ではすでに危険にさられています。いつでも一番安全にウェブサイトをブラウジングする方法を学びましょう。

危険にさらされるブラウザの影響を小さくするやり方はいくつかあります。しかし、本当に効果のある方法を使うには、自身のワークステーションの使い方を大きく変更する必要があります。

１: 2つの違うブラウザを使う（必須）

これが一番簡単な方法ですが、セキュリティの強度はそれほど高くありません。ブラウザがセキュリティ侵害されたからといって、攻撃者があなたのシステム全体に自由にアクセスできるようになるわけではありません。ローカルのブラウザストレージを読んで、他のタブレットから起動中のセッションを盗み、ブラウザへの入力を取り込むなどの限られたものになることがしばしばです。2つの別のブラウザを、1つは仕事用・高セキュリティを要するサイト用として、もう１つをそれ以外の全てのために使うことで、小さなセキュリティ侵害から攻撃者にクッキー全体にアクセスできるようしてしまうことを防いでくれます。この方法の不便なことは、2つのブラウザを使用するため、メモリ消費が多いということです。

以下が私たちのお勧めです。

仕事やセキュリティを確保する必要のあるサイトにはFirefoxを使う

攻撃者の手に絶対に渡ってほしくないクッキーやセッション、ログイン情報、キーストロークなどのデータの保証のために細心の注意が必要になるサイトにはFirefoxを使ってアクセスしてください。厳選されたサイトにアクセスする以外には、このブラウザは使わないでください。

以下のFirefoxのアドオンをインストールしましょう。

• NoScript （必須）

  • NoScriptはユーザがホワイトリストに登録したドメイン以外からの有効なアクティブコンテンツを読み込むことを防ぎます。デフォルトのブラウザで使うのはとても使いづらいので（セキュリティ性はとても高いのですが）、仕事に関係するサイトへのアクセスに使うブラウザにのみで適用することをお勧めします。

• Privacy Badger （必須）

  • EFFのPrivacy Badgerは外部のトラッカーや広告プラットフォームを読み込むのを防ぎ、それらのトラッキングサイトでの侵害があなたのブラウザに影響を与えるのを防止する手伝いをしてくれるのです（トラッカーと広告サイトは、世界規模で何千ものシステムに素早く感染させられるので、よく攻撃者にターゲットにされます）。

• HTTPS Everywhere （必須）

  • EFFが開発したこのアドオンは、クリックしたリンクがhttp://を使っていたとしても、ほとんどのあなたのサイトが安全にアクセスされるのを保障してくれます。（ SSL-strip のような数多くの攻撃を防ぐのに便利です）。

• Certificate Patrol （好ましい）

  • このツールは、あなたのアクセスしたサイトが、最近TSL証明書を変更している場合に通知をくれます。特に、その変更が期限切れの日が近くなかった場合や、変更後違った証明書機関を使っている場合などにアラートを出します。そして、誰かがあなたのコネクションに中間者攻撃を試みようとしていることに気付く手助けとなります。ただし、良性の誤検出もよく出してしまいます。

NoScriptは、アクティブコンテンツのほとんどを読み込んだり実行したりするのを防いでくれますので、リンクを開くためのデフォルトブラウザとしてFirefoxを残すことをお勧めします。

他の用途にはChrome/Chromiumを使う

Chromiumの開発者は、セキュリティに関する優れた機能を多く追加することに関してFirefoxより勝っています（少なくとも Linux では）、例えば、seccompのサンドボックスや、カーネルのユーザ名前空間などです。これらはあなたがアクセスしたサイトと他のシステムとの間で、追加された独立したレイヤとして機能します。Chromiumは上流のオープンソースプロジェクトで、ChromeはChromiumプロジェクトをベースにしたGoogleのプロプライエタリなバイナリビルドです（Googleに知られたくないことのために、Chromeを使わないように普段通りに細心の注意を払ってください）。

Privacy Badger や HTTPS Everywhere のアドオンをChromeにもインストールすることをお勧めします。そして、これは”信頼性のないサイト”のブラウザですよ、と示すためにFirefoxとは異なるテーマを与えてください。

2,　異なる2つのブラウザを使う。1つは専用の仮想マシンの中に(好ましい)

これは上記の項目と同じようですが、「セキュアな用途以外のため」のブラウザを専用の仮想マシン内で起動する点が異なります。この時、この仮想マシンは高速なプロトコルで通信でき、クリップボードやサウンドイベント(SpiceやRDPなど)を共有できるものを使います。これにより、信頼性の低いブラウザと他の仕事環境を明確に別のレイヤーに分離することができるので、あなたのブラウザを完全にセキュリティ侵害しようとする攻撃者も、残りのシステムにたどり着くためにはさらに仮想マシンの独立したレイヤを破らなくてはいけません。

これは驚くほど便利な構成ですが、大きなRAMを必要とし、大きな負荷を扱える速いプロセッサが必要となります。また、適切に実行作業を調整する必要のある管理者の役割に力と時間を注ぐ必要があります。

3.　仮想化で仕事と遊びの環境を完全に分ける（こだわり）

Qubes-OS project を見てください。これは、アプリケーションが完全に独立した仮想マシンに影響を及ぼさないようにすることで、高いセキュリティ性のあるワークステーション環境を提供しようとします。

パスワードマネージャ

チェックリスト

• パスワードマネージャを使う （必須）
• 関連性のないサイトでは個別のパスワードを使う （必須）
• チーム内での共有をサポートしているパスワードマネージャを使う （好ましい）
• Webサイト以外のアカウントには別のパスワードマネージャを使用する（好ましい） （好ましい）

検討事項

チームメンバ全員が適切、かつ個別のパスワードを使うことが重要です。認証情報の盗難は常に起こっています。例えば感染したワークステーションから、盗難されたデータベースのダンプから、リモートサイトからのエクスプロイトから、そして他のあらゆる手段を通じてです。特に重要なアプリケーションに関しては、決してサイトをまたがって認証情報を使うべきではありません。

ブラウザに統合されたパスワードマネージャ

すべてのブラウザはかなり安全なパスワード保存のメカニズムを備えていて、ユーザが設定したパスフレーズによってデータを暗号化したまま、ベンダが管理するクラウドストレージと同期することができます。しかしこのメカニズムには重大な欠点があります。

1. ブラウザを越えて機能しない
2. チームメンバ間で認証情報を共有する方法がない

無料または安価な、信頼できるパスワードマネージャがいくつかあります。複数のブラウザに統合することができ、様々なプラットフォームで使うことができ、グループシェアリング機能（通常は有料）も提供しています。検索エンジンで簡単に解決法は見つけられますよ。

スタンドアローンのパスワードマネージャ

ブラウザに統合されているパスワードマネージャの1つの大きな欠点は、それが最も侵入者に攻撃されやすいアプリケーションの一部であるという点です。そのことを不安に感じるなら（そうであるべきです）2つの異なるパスワードマネージャを使ってもいいでしょう。1つはブラウザに統合されたWebサイト用、そしてもう1つはスタンドアローンのアプリケーションとして稼働するものです。後者はルート用パスワード、データベースのパスワード、他のシェルアカウントの認証情報など、リスクの高い認証情報を保存するのに使います。

例えばスーパーユーザのアカウント認証情報などをチームメンバと共有する時に便利に使うこともできそうです（他、サーバのルート用パスワード、ILOパスワード、データベースの管理者パスワード、ブートローダのパスワードなど）。

下記に挙げるようなツールが便利です。
* KeePassX は、バージョン2からチーム共有の機能が強化されている
* Pass はテキストファイルとPGPを使い、gitで統合できる
* Django-Pstore は、GPGを使って管理者間で認証情報を共有できる
* Hiera-Eyami は、インフラにすでにPuppetを使っているなら、暗号化されたHieraデータストアの一部としてサーバ/サービスの認証情報をトラックするのに便利かもしれない

SSHとPGP秘密鍵の安全を確保する

SSHやPGP秘密鍵などの個人の暗号化キーはあなたのワークステーション上で最も価値の高いもの、つまり攻撃者にとって最も取得したいものであるはずです。盗み出せばそこからインフラを攻撃したり、他の管理者に対してあなたになりすましたりすることができるからです。あといくつか手段を講じて、あなたの秘密鍵を盗難から守りましょう。

チェックリスト

• 秘密鍵を保護するのには安全性の高いパスフレーズを使う （必須）
• PGPマスターキーはリムーバブルストレージに保存しておく （好ましい）
• 認証、署名と暗号化されたサブキーはスマートカードデバイスに保存しておく （好ましい）
• ssh秘密鍵としてPGP認証キーを使うようにSSHを設定しておく （好ましい）

検討事項

秘密鍵の盗難を防ぐ最も良い方法は、スマートカードを使って暗号化された秘密鍵を保管し、決してワークステーション上にはコピーしないことです。OpenPGP対応のデバイスを提供している会社がいくつかあります。

• Kernel Concepts ではOpenPGP互換のスマートカードや、必要ならUSBリーダも購入できる
• Yubikey NEO ではOpenGPGのスマートカード機能の他、気の利いた機能がたくさんついてくる（U2F、PIV、HOTPなど）

マスターのPGPキーがメインのワークステーションに保存されていないこと、そしてサブキーだけが使用されていることを確認することも重要です。マスターキーが必要となるのは、他の誰かのキーを認証する時か新しいサブキーを作成するときだけで、これは頻繁に起こる処理ではありません。 Debianのサブキー ガイドを参照すれば、どうやってあなたのマスターキーをリムーバブルストレージに移動するのか、どうやってサブキーを作成するかについて学ぶことができます。

それからGnuPG エージェントをsshエージェントとして使うよう設定し、スマートカードベースのPGP認証鍵をssh秘密鍵として使います。私たちは、スマートカードリーダまたはYubikey NEOを使った場合の 詳細なガイド を公開しています。

そこまでやるつもりがなくても、最低限、安全性の高いパスフレーズがPGP秘密鍵とSSH秘密鍵に対して設定されていることを確認してください。そうすれば、攻撃者が盗み出したり使用したりするのが困難になります。

ハイバネートまたはシャットダウンを慣行し、サスペンドはしないこと

システムがサスペンドされるとRAMの内容はメモリに保持され、攻撃者が閲覧できるようになってしまいます（ コールドブート攻撃 として知られています）。ある一定の時間システムから離れる場合、例えば業務終了時などは、シャットダウンまたはハイバネートして、サスペンドやつけっぱなしは避けましょう。

ワークステーションでSELinuxを使う

SELinuxにバンドルされているディストリビューションを使っている場合（Fedoraなど）、あなたのワークステーションのセキュリティを最大限に高めるためにうまく活用できる方法について、お勧めを以下にリストします。

チェックリスト

• ワークステーションでSELinuxがEnforcing（アクセス制御が有効）になっていることを確認 （必須）
• やみくもに audit2allow -M , を実行せず、常に確認する （必須）
• 決して setenforce 0 を実行しない （好ましい）
• アカウントをSELinuxユーザ staff_u に切り替える （好ましい）

検討事項

SELinuxはCoreのPOSIX permissionの機能に対する強制制御（MAC）の機能拡張で、円熟していて、堅牢です。最初にリリースされてから長い道のりを歩んできました。それにもかかわらず、多くのシステム管理者は古臭い念仏のように「無効にしなさい」と言うのです。

とは言うものの、SELinuxにはワークステーション上で限られたセキュリティの利点しかありません。と言うのも、ユーザとして実行する多くのアプリケーションは制限なしで実行されるからです。しかし有効にしておけば実質的な利点があります。脆弱なデーモンサービスを経由して攻撃者がルートレベルのアクセスを得られるよう権限を上げようとするのを阻止できるからです。

お勧めするのは、有効にしておいて、Enforcingにすることです。

決して setenforce 0 を行わない

SELinuxを一定の時間Permissiveモードにするのに、 setenforce 0 を使いたい誘惑に駆られますが、それは避けましょう。本来の目的は特定のアプリケーションまたはデーモンをトラブルシュートすることなのに、こうするとシステム全体に対してSELinuxを無効にしてしまうからです。 setenforce 0 ではなく、 semanage permissive -a [somedomain_t] を使って、該当のドメインだけをPermissiveモードにしましょう。まず、最初にどのドメインが問題を起こしているのかを ausearch を実行して捜します。

ausearch -ts recent -m avc

それから、以下のように scontext= (source SELinux context)を捜します。

scontext=staff_u:staff_r:gpg_pinentry_t:s0-s0:c0.c1023
                   ^^^^^^^^^^^^^^

拒否されているドメインは gpg_pinentry_t だと分かりました。アプリケーションをトラブルシュートしたい場合、これをPermissiveドメインに追加する必要があります。

semange permissive -a gpg_pinentry_t

こうすれば、そのアプリケーションを使ってAVCの残りを収集できます。そしてローカルポリシーを記述するために audit2allow と共に使うことができます。そうすれば新たなAVC の拒否は発生しないので、次のように実行してそのドメインのPremissiveモードを解除できます。

semanage permissive -d gpg_pinentry_t

SELinuxのstaff_rロールでワークステーションを使用する

SELinuxには、ユーザアカウントに関連したロールに基づいた特定の権限を禁止したり許可したりするロールがネイティブに実装されています。管理者として、あなたは staff_r ロールを使うべきで、これは sudo しない限り多くのコンフィギュレーションや他の機密性の高いファイルへのアクセスを制限します。
デフォルトでは unconfined_r としてアカウントが作成され、ほとんどのアプリケーションは制限なしで実行され、まったくSELinuxの制限を受けません（または非常に少ない）。アカウントを staff_r に切り替えるには、次のコマンドを実行してください。

usermod -Z staff_u [username]

一度ログアウトして再度ログインすれば新しいロールが有効になり、この時点で id -Z を実行すれば、次のように表示されます。

staff_u:staff_r:staff_t:s0-s0:c0.c1023

sudo を実行する時、SELinuxに”システム管理者”のロールへ移行するように指示するためのフラグを追加することを忘れないようにしましょう。コマンドは次の通りです。

sudo -i -r sysadm_r

id -Z をすれば、次のように表示されます。

staff_u:sysadm_r:sysadm_t:s0-s0:c0.c1023

注意： この切り替えの前に、 ausearch と audit2allow の使い方に慣れておいたほうがいいでしょう。 staff_r のロールでは実行できないアプリケーションがある可能性があるからです。これを書いている時点では、ポリシーに変更をかけなければ staff_r では動作しない、有名なアプリケーションを下記に挙げます。

• Chrome/Chromium
• Skype
• VirtualBox

unconfined_r に戻すには、次のコマンドを実行してください。

usermod -Z unconfined_u [username]

それからログアウトして、再度、安全な環境へとログインしましょう。

参考文献

ITセキュリティの世界は底なしの穴のようなものです。深く行けば行くほど、個々のディストリビューションのセキュリティ機能について発見があるでしょう。下記のリンクを参照してみてください。

• Fedora Security Guide
• CESG Ubuntu Security Guide
• Debian Security Manual
• Arch Linux Security Wiki
• Mac OSX Security