新規の Ansible Tower は、一般的な環境を自動化する安全な方法でデプロイされます。ただし、特定のオペレーティングシステム環境、自動化、および自動化プラットフォームを管理するには、セキュリティーを確保するいくつかの追加ベストプラクティスが必要になる場合があります。本書では、安全な方法で自動化するためのベストプラクティスを説明します。
アプリケーションは、基礎となるシステムと同じくらい安全です。Red Hat Enterprise Linux を保護するには、まずリリースに適したセキュリティーガイドを参照してください。
Red Hat Enterprise Linux 7 の場合: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/
Red Hat Enterprise Linux 8 の場合: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/index
Ansible および Ansible Tower は、汎用的で宣言型の自動化プラットフォームから構成されます。つまり、Ansible Playbook が (Tower 経由、または直接コマンドラインで) 起動すると、Ansible に提供される Playbook 、インベントリー、および認証情報が信頼できるソースと見なされます。特定の Playbook コンテンツ、ジョブ定義、またはインベントリーコンテンツの外部検証に関するポリシーが必要な場合、このプロセスは、自動化を開始する前に (Tower Web UI または Tower API を介して) 実行する必要があります。
これには多くの形式を使用できます。ソース管理、分岐、および必須のコードレビューの使用が、Ansible オートメーションのベストプラクティスになります。この方法でソース管理を使用してプロセスフローを作成するのに役に立つツールは多数あります。
より高度なレベルでは、自動化を含む任意のワークフローに関する承認とポリシーベースのアクションの作成を可能にする多くのツールが存在します。このようなツールは、Tower の API を介して Ansible を使用して自動化を実行できます。
システムの特定の部分へのアクセスを許可すると、セキュリティーリスクが露呈します。安全なアクセスを支援するには、次のプラクティスを適用します。
安全なシステムを維持するには、システム管理アカウントへのアクセスを最小限に抑えることが重要です。システム管理者 (root) ユーザーは、システムアプリケーションへのアクセス、編集、および中断が可能になります。root アクセス権を持つユーザー (アカウント) の数を、可能な限り少数のグループにします。信頼できないユーザーに、root または awx (Tower ユーザー) への sudo を付与しないでください。sudo などのメカニズムを使用して管理アクセスを制限する場合は、特定のコマンドセットに制限すると、依然として広範囲のアクセスが提供される可能性があることに注意してください。シェルまたは任意のシェルコマンドの実行を許可するコマンド、またはシステムのファイルを変更できるコマンドは、基本的に完全な root アクセスと同等です。
Tower のコンテキストでは、Tower の「システム管理者」または「スーパーユーザー」のすべてのアカウントが、Tower のインベントリーまたは自動化定義を編集、変更、更新できます。これを、低レベルの Tower 設定と災害復旧でのみ可能な最小ユーザーセットに制限します。
ベストプラクティスと併用する場合は、Ansible Tower は管理目的を除き、ローカルユーザーアクセスを必要としません。管理者以外のユーザーは Tower システムにアクセスできません。
自動化認証情報が Tower にのみ保存されている場合は、安全性が増します。OpenSSH などのサービスは、特定のアドレスからの接続でのみ認証情報が可能になるように設定できます。自動化で使用される認証情報は、災害復旧やその他のアドホック管理にシステム管理者が使用する認証情報とは変えることができ、これにより監査を容易にします。
異なるレベルのシステムにアクセスするために、さまざまな自動化が必要になる場合があります。たとえば、パッチを適用してセキュリティーベースラインチェックを実行する低レベルのシステム自動化や、アプリケーションをデプロイする高レベルの自動化などです。自動化の各部分に異なるキーまたは認証情報を使用することにより、1 つのキー脆弱性の影響が最小限に抑えられ、ベースライン監査も容易になります。
Tower などに、安全なプラットフォームを確保するリソースがいくつかあります。次の機能の利用を検討してください。
管理アクセスの場合は、アクションの監査および監視を行うことが重要です。システム全体では、これは組み込みの監査サポート ( https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/chap-system_auditing.html) 内、および組み込みのロギングサポートを介して実行できます。
Ansible Tower の場合、これは、Tower 内のすべての変更を記録する組み込みのアクティビティーストリームサポートと、自動化ログを介して行われます。
ベストプラクティスでは、ローカルシステムでログを確認する代わりに、ロギングと監査を一元的に収集する必要があります。ご利用の環境で標準的な IDS または ロギング/監査 (Splunk)、もしくはその両方を使用するように Ansible Tower を設定することが推奨されます。Ansible Tower には、Elastic Stack、Splunk、Sumologic、Loggly などの組み込みロギング統合が含まれます。詳細は、Tower のロギングおよびアグリゲーション を参照してください。
SELinux を無効にしないでください。また、Tower の既存のマルチテナントコンテインメントを無効にしないでください。Tower のロールベースのアクセス制御 (RBAC) を使用して、自動化の実行に必要な最小限の特権を委譲します。Tower のチームを使用して、個々のユーザーではなくユーザーグループにパーミッションを割り当てます。『Ansible Tower User Guide』の「ロールベースのアクセス制御」を参照してください。
Tower だけですべてのユーザーを維持すると、大規模な組織では時間のかかるタスクになり、エラーが発生しやすくなる可能性があります。Ansible Tower は、「LDAP」、「SAML 2.0」、および特定の「OAuth providers」を介した外部アカウントソースへの接続をサポートします。これにより、パーミッションを操作する際のエラーの原因がなくなります。