フローを保護するにはどうすればよいですか？つまり、許可されたアプリケーションのみをアサートし、NiFiにデータを送信する方法は？たとえば、すべての発信者とそのアクセス許可（およびポリシー）を登録する場所など、フローをLDAPに接続できますか。発信者ごとのフローを保護する
私はログインするユーザーに関してNiFiを保護する可能性しか見ていませんが、これは私の質問とは関係ありません。
[Update 2/10/2017] AWS IoTの確認AWSCredentialsProviderControllerServiceが使用されています。同様に、私たちのプロセスを保護するために私たちの認証/認可サービスを開発することができますか？ LDAPやDBの統合にこのようなサービスはありますか？
その後、権限が入力ポートごとに割り当てることができ、あなたは、サイトツーサイトNiFiインスタンス間、またはMiNiFiからNiFiに行っている場合、データがNiFi ...
に入っているかによって決まります。
外部のNiFi/MiNiFiは、中央のNiFiを認証するための証明書を必要とするため、中央NiFiのユーザとして適切な権限が与えられている必要があります。
このポストは、2つのNiFiインスタンス間のセキュアな通信の一例を示している： https://bryanbende.com/development/2016/08/30/apache-nifi-1.0.0-secure-site-to-site
データは、ListenHTTP、ListenTCP、又は同様のものなどのプロセッサを介して入力している場合、それはプロセッサが実装されている方法に依存。これらのプロセッサのほとんどは、双方向のTLS/SSLを提供する必要があります。そのため、特定のトラストストアから証明書を発行したクライアントだけが接続できるようになります。
これらのケースでは、発信者は、認可の決定を下すNiFiフレームワークではないため、ユーザーとして表示される必要はありません。
こんにちはブレインとあなたの答えに感謝します。サイトツーサイトは問題の範囲外です。呼び出し元が証明書を持っている（プロセッサでサポートする）か、プロセッサ呼び出し者ごとに1人のユーザーを作成するか（https://nifi.apache.orgに従ってプロセッサにデータを送信するために呼び出し元を認証できるポリシー/docs/nifi-docs/html/administration-guide.html#access-policies？） –
ちょうどそれを明確にするために、質問はNiFiへのデータのシステム間提出を「安全に」確保することに関係していますUIアクセス）。 –
NiFiフレームワークは、プロセッサによって起動されるサーバへのアクセス制御を行うことはできません...つまり、ListenHTTPが起動されると、組み込みWebサーバが起動され、NiFiフレームワークはこれに関する知識がなく、それに対してセキュリティポリシーを実施するため、双方向TLS/SSLのみに依存することができます –