ネットワーク認証+ローミングホームディレクトリ-どのテクノロジーの使用を検討すべきですか？
複数のコンピューター間でユーザーに単一のIDを提供するソフトウェアを調べています。つまり、ユーザーは各コンピューターで同じアクセス許可を持っている必要があり、ユーザーは各コンピューターのすべてのファイル（ローミングホームディレクトリ）にアクセスできる必要があります。この一般的な考え方には多くの解決策があるようですが、私は自分に最適な解決策を見つけようとしています。要件とともに詳細を次に示します。
- マシンのネットワークは、Ubuntuを実行するAmazon EC2インスタンスです。
- SSHを使用してマシンにアクセスします。
- このLAN上の一部のマシンにはさまざまな用途がある場合がありますが、ここでは特定の用途（マルチテナンシープラットフォームを実行している）のマシンについてのみ説明します。
- システムは必ずしも一定数のマシンを備えているとは限りません。
- 実行中のマシンの数を永続的または一時的に変更する必要がある場合があります。これが、私が一元化された認証/ストレージを検討している理由です。
- この効果の実装は安全なものでなければなりません。
- ユーザーがシェルに直接アクセスできるかどうかはわかりませんが、ユーザーのソフトウェアはシステム上で（もちろん、制限されたLinuxユーザー名で）実行される可能性があります。これはシェルへの直接アクセスと同じくらい優れています。
- 彼らのソフトウェアがセキュリティのために悪意のある可能性があると仮定しましょう。
目標を達成するためのいくつかのテクノロジー/組み合わせについて聞いたことがありますが、それぞれの影響についてはよくわかりません。
- 古いServerFaultの投稿では、NFSとNISが推奨されていましたが、 Symantecによるこの古い記事 によると、この組み合わせにはセキュリティ上の問題があります。この記事はNIS +への移行を提案していますが、古いため、 このウィキペディアの記事 はSunによるNIS +からの脱却を示唆するステートメントを引用しています。推奨される代替品は、私が聞いた別のことです...
- LDAP。 LDAPを使用して、ユーザー情報をネットワーク上の集中管理された場所に保存できるようです。 「ローミングホームフォルダ」の要件を満たすには、NFSを使用する必要がありますが、それらの参照が一緒に使用されているようです。ノートンライフロックの記事でNISとNFSの両方のセキュリティ問題が指摘されているので、NFSを置き換えるソフトウェアはありますか、それともその記事のロックダウンに関する提案に注意する必要がありますか？ 私はLDAPを好む傾向があります。これは、アーキテクチャのもう1つの基本的な部分であるRabbitMQにLDAP用の認証/承認プラグインがあるためです。 RabbitMQはシステム上のユーザーに制限された方法でアクセスできるので、できればセキュリティシステムを結び付けたいと思います。
- Kerberosは、私が聞いたもう1つの安全な認証プロトコルです。私は数年前に暗号学のクラスでそれについて少し学びましたが、それについてあまり覚えていません。私はオンラインでいくつかの方法でそれを組み合わせることができるという提案を見ましたwith LDAP。これは必要ですか？ KerberosなしのLDAPのセキュリティリスクは何ですか？また、カーネギーメロン大学が開発した別のソフトウェアでKerberosが使用されていたことも覚えています...
- Andrew File System、またはAFS。 OpenAFSは使用可能ですが、セットアップは少し複雑に見えます。私の大学では、AFSが両方の要件を提供しています...どのマシンにもログインでき、「AFSフォルダー」は常に使用可能です（少なくともAFSトークンを取得するとき）。
どのパスを調べるべきかについての提案とともに、特に役立つガイドはありますか？太字のテキストが指摘しているように、LDAPが最良の選択のように見えますが、セキュリティに関する実装の詳細（Keberos？NFS？）に特に興味があります。
認証、許可、およびディレクトリ情報
これはあなたの質問に対する完全な答えではありませんが、NIS、LDAP、Kerberosについての質問に対処するのに役立つかもしれないと思いました。
this から始めます。これは、authenticationとauthorizationの違いの概要を示しています。 、これはこの種の議論のために理解することが重要です。
Kerberosは、あなたが言うようにjust認証プロトコルです。資格情報のセット（ユーザー名とパスワードなど）が与えられると、それらが有効かどうかがわかります。これですべてです。
対照的に、NISとLDAPはどちらもディレクトリサービスです。これにより、クライアントはユーザーに関する情報を照会できます（ホームディレクトリは何ですか？ユーザーIDは何ですか？）。どちらも、さまざまな問題の程度を伴う認証ソースとして使用できます。
NISは、それ自体では実際には認証を実行しません。代わりに、パスワードハッシュをクライアントマシンに公開し、ローカルシステムはローカルアカウントの場合と同じ方法で実際の認証手順を実行します。ここでの問題は、NISクライアントの1つにアカウントを持つ誰もがすべてのパスワードハッシュを取得し、余暇にブルートフォース攻撃を仕掛けることができることです。
LDAPは、認証ステップが実際にサーバー上で実行されるため、いくらか安全です。 LDAPセッションをSSLまたはTLSで暗号化していることを確認する必要があります。そうしないと、パスワードがネットワーク上でクリアテキストで公開され、パケットスニッフィングに対して脆弱になります。
認証にKerberosを使用し、次に承認（通常は「グループメンバーシップ」を意味する）とディレクトリ情報にNISまたはLDAPを使用することは非常に一般的です。 NISは、（認証をKerberosに移動することによって）パスワードハッシュを削除すると、LDAPよりも安全性が低くなることはなく、最新のLinuxディストリビューションで「すぐに使用できる」という利点があると主張します。
一方、LDAPは一般にはるかに拡張性が高く、ユーザー（または他のディレクトリオブジェクト）が多数ある場合は拡張性が高く、豊富なクエリを提供し、一般的に管理しやすくなっています。 LDAPはさまざまなアプリケーションでネイティブにサポートされていますが、NISはコアオペレーティングシステムと奇妙な近親相姦関係にあり、望ましくない場合があります。
ゼロから構築する場合は、認証にはKerberos、ディレクトリサービスにはLDAPをお勧めします。
ファイルシステム
NFSには大きな利点があります。すでに持っていて、広く展開されており、一般的に安定しています。 NFSには2つの主な欠点があります。
パラレルI/Oでは適切に拡張できません。同じファイルシステムにアクセスするマシンの数が多い場合、単一のNFSサーバーは追いつくのに苦労するかもしれません。これが、大規模なクラスターが通常、並列I/Oをサポートするように設計されたクラスターファイルシステム（Lustre、GlusterFS、GPFS、GFSなど）を使用する理由です。
セキュリティモデルが悪い。通常、NFSセキュリティの決定は、完全に数値のユーザーIDに基づいています。 NFSファイルシステムをマウントできるシステムにrootがいる場合、すべてのファイルにアクセスできます。適切なユーザーIDでローカルユーザーをいつでも作成できるためです。 NFSv3とNFSv4の両方がKerberos認証をさまざまなレベルでサポートしているため、これは厳密に真実ではありませんが、これを使用している人にはまだ会っていません。 。したがって、マイレージは異なる場合があります。
小規模な展開の場合、ほとんどの人は制限があるにもかかわらず、NFSを使用するだけです。
他にもさまざまなソリューションがあります（前述のクラスターファイルシステムやAFSなど）が、これらのほとんどは、選択したディストリビューションで実行するために、ユーザー側で何らかの作業が必要になります。最近、GlusterFSについて良いことを聞いたので、NFSの代替手段を探していたら、それが最初に探す場所かもしれません。
これは部分的な答えです。
NIS/NIS +
NISを使用しないでください。 nisスキーマでLDAPを使用します。
OpenLDAP（別名Ubuntuではslapd）
適切なACLとSSF（セキュリティ強度係数）を必ず設定してください。
注意しないと、パスワードを平文で送信するのは非常に簡単です。
http://www.openldap.org/doc/
[〜＃〜] nfs [〜＃〜]
NFSは暗号化されていません。
いくつかのトリックを使ってSSLでラップすることができます。
Kerberosがない場合、認証はip_addrに依存します。
Kerberosでは、SASLを使用してすべてを暗号化することが可能です。
Kerberos
LDAP認証のためにOpenLDAPにSASLパススルー認証が必要です。 （難しくない。）
DNSエントリを使用する必要があります。 （必須ではありませんが、非常に便利です）。
ssh-keysの代わりにGSSAPIを使用できます。 （共存できます。）
KDCマシンはクライアントマシンから分離する必要があります。
OpenAFS
DESで暗号化されています。 （安全とは見なされません。）
Kerberosまたはそれ自身のレガシー認証サーバーが必要です。
独自のファイルシステムACLがあります。