Security
has evolved into a primary concern that can no longer be taken for
granted. The inherent security in Windows Server 2008 R2 is only as good
as the services that have access to it; therefore, it is wise to
perform a security audit of all systems that access information from
servers. This concept holds true for management systems as well because they
collect sensitive information from every server in an enterprise. This
includes potentially sensitive event logs that could be used to
compromise a system. Consequently, securing the OpsMgr infrastructure
should not be taken lightly.
Securing OpsMgr Agents
Each server that contains
an OpsMgr agent and forwards events to management servers has specific
security requirements. Server-level security should be established and
should include provisions for OpsMgr data collection. All traffic
between OpsMgr components, such as the agents, management servers, and
database, is encrypted automatically for security, so the traffic is
inherently secured.
In addition,
environments with high-security requirements should investigate the use
of encryption technologies such as IPSec to scramble the event IDs that
are sent between agents and OpsMgr servers, to protect against
eavesdropping of OpsMgr packets.
OpsMgr uses mutual
authentication between agents and management servers. This means that
the agent must reside in the same forest as the management server. If
the agent is located in a different forest or workgroup, client
certificates can be used to establish mutual authentication. If an
entire nontrusted domain must be monitored, the gateway server can be
installed in the nontrusted domain, agents can establish mutual
authentication to the gateway server, and certificates on the gateway
and management server are used to establish mutual authentication. In
this scenario, you can avoid needing to place a certificate on each
nontrusted domain member.
Understanding Firewall Requirements
OpsMgr servers that are
deployed across a firewall have special considerations that must be
taken into account. Port 5723, the default port for OpsMgr
communications, must specifically be opened on a firewall to allow
OpsMgr to communicate across it.
Table 23.1 describes communication for this and other OpsMgr components.
Table 23.1. OpsMgr Communication Ports
From | To | Port |
---|
Agent | Root Management Server | 5723 |
Agent | Management server | 5723 |
Agent | Gateway server | 5723 |
Agent (ACS forwarder) | Management server ACS collector | 51909 |
Gateway server | Root Management Server | 5723 |
Gateway server | Management server | 5723 |
Management or Gateway server | UNIX or Linux computer | 1270 |
Management or Gateway server | UNIX or Linux computer | 22 |
Management server | Operations Manager database | 1433 |
Management server | Root Management Server | 5723, 5724 |
Management server | Reporting data warehouse | 1433 |
Management server ACS collector | ACS database | 1433 |
Operations Console | Root Management Server | 5724 |
Operations Console (reports) | SQL Server Reporting Services | 80 |
Reporting server | Root Management Server | 5723, 5724 |
Reporting server | Reporting data warehouse | 1433 |
Root Management Server | Operations Manager database | 1433 |
Root Management Server | Reporting data warehouse | 1433 |
Web console browser | Web console server | 51908 |
Web console server | Root Management Server | 5724 |
The
firewall port for the agents is the port that needs to be opened most
often, which is only port 5723 from the agent to the management servers
for monitoring. Other ports, such as 51909 for ACS, are more rarely
needed. Figure 1 shows the major communications paths and ports between OpsMgr components.
Outlining Service Account Security
In
addition to the aforementioned security measures, security of an OpsMgr
environment can be strengthened by the addition of multiple service
accounts to handle the different OpsMgr components. For example, the
Management Server Action account and the SDK/Configuration service
account should be configured to use separate credentials, to provide for
an extra layer of protection in the event that one account is
compromised.
Management Server Action account— The account responsible for collecting data and running responses from management servers.
SDK and Configuration service account— The account that writes data to the operations database; this service is also used for all console communication.
Local Administrator account— The account used during the agent push installation process. To install the agent, local administrative rights are required.
Agent Action account—
The credentials the agent will run as. This account can run under a
built-in system account, such as Local System, or a limited domain user
account for high-security environments.
Data Warehouse Write Action account— The account used by the management server to write data to the reporting data warehouse.
Data Warehouse Reader account— The account used to read data from the data warehouse when reports are executed.
Run As accounts—
The specific accounts used by management packs to facilitate
monitoring. These accounts must be manually created and delegated
specific rights as defined in the management pack documentation. These
accounts are then assigned as Run As accounts used by the management
pack to achieve a high degree of security and flexibility when
monitoring the environment. New to OpsMgr 2007 R2 is the ability to
selectively distribute the Run As Account to just the agents that need
them.