CAP Server Implementation Architecture Guidelines
Overview
The Consolidated Access Point (CAP) servers are intended to:- Allow access to MnSCU ITS ad hoc reporting databases from secured computers.
- Prevent access to MnSCU ITS ad hoc reporting databases from unsecured computers.
- Enable campus ITS managed security and access controls on
all ad hoc database access. - Enable auditable access to ad hoc databases.
- Consolidate ad hoc access to a limited number of actively managed servers.
This diagram illustrates how the CAP server will be used to connect
to any database in the data center:
As shown in the diagram, all campus access to the Oracle servers in the data center must come from CAP servers. Direct access from any other source (such as staff computers) will be blocked. Only administrators should be allowed access to the CAP server from inside the network; all other segments (such as students) should be blocked.
Each institution is responsible for purchasing and configuring its own CAP server according to the requirements in this document. MnSCU ITS will enable access to the Oracle server from a CAP server; the process for requesting access is described later in this document.
Specifically:
- Campuses connect to the Oracle database exclusively from campus defined CAP servers.
- CAP servers connect to the Oracle database exclusively on the RARE database port(s) (currently TCP port 1707).
- CAP servers must be secured before they will be allowed access to RARE.
- CAP servers must be on secured network segments before they will be allowed access to RARE.
- No databases other than REPL are listening on the above port(s).
- Oracle VPD (Row level security) is used to prevent campuses from accessing all but their own data.
Security Requirements
Ad hoc access to the REPL database will be permitted from approvedCAP servers only.
The following requirements must be met prior to allowing access to the REPL ad-hoc database:
General
- The server must be secured to meet standards in Information Security Standards and Guidelines .
- The network must be segmented per the Network Segmentation Standard.
- Network access rules must be documented as in the
(Sample Firewall Exception Document). - Access to the CAP server will be via approved protocols only. Currently, the datacenter firewall allows connectivity only via TCP port 1707 from CAP servers. The REPL server will accept only encrypted Oracle communications on this port.
Specific
- CAP servers must have anti-virus protection.
- Antivirus protection must be automatically updated.
- Logs must be maintained of anti-virus updates.
- CAP server must have automatic or semi-automatic patch management.
- CAP servers must automatically check for security updates.
- Campuses may elect to schedule application of
updates.
- CAP servers are automatically defined as ‘PROTECTED’
servers holding ‘PERSONAL DATA’. - CAP servers cannot be directly accessible from the Internet.
- CAP servers may not directly access the Internet except for vendor patches and antivirus updates.
- User access to CAP servers shall be restricted to protocols HTTPS, RDP, and ICA. TLS-enabled RDP and SecureICA are strongly encouraged.
- Access to CAP servers must be logged.
- CAP servers must be restricted to data access applications only.
- Users accessing REPL data via CAP servers must not have administrator or system privileges on CAP servers.
Data Flows
| Flow | Permitted Ports |
|---|---|
| CAP Server to Oracle Databases | TCP 1707 |
| CAP Server to anywhere else | Only as needed for patch and virus updates |
| Internet to CAP Server | NONE |
| Administrators to CAP Server | HTTPS, RDP, ICA |
| Non-Administrators, Students, or Public to CAP Server | NONE |
Filtering Guidelines
There are multiple ways to control traffic to and from the CAP
server. In general firewalls are best, IOS firewalls (CBAC) are
good, and static access lists are acceptable.
Traffic filtering must deny traffic by default. In other words, the last (possibly implied) rule in an access list or firewall rule set must be to drop all packets that aren't explicitly permitted.
Some guidelines for creating static access lists:
- Don't use a "permit tcp any any established" rule to allow return traffic. Instead, make individual ACL entries using the "established" keyword for those that use TCP.
- Narrow down port ranges as much as possible, not only for destination ports, but also for source ports.
- Restrict DNS access to specific servers. Those servers can be internal campus servers or these central servers:
- 199.17.241.241
- 156.98.1.1
- 207.171.71.71
- 207.171.88.188
- The Oracle servers are currently:
- Production: 199.17.242.1
- Development: 199.17.242.4
Example access lists entries for access to the production Oracle
server (ACL 101 filters traffic from the CAP server, ACL 102 filters traffic to the CAP server, and host x.x.x.x is the CAP server):
access-list 101 permit tcp host x.x.x.x gt 1023 host 199.17.242.1 eq 1707
access-list 102 permit tcp host 199.17.242.1 eq 1707 host x.x.x.x gt 1023 established
Sizing Guidelines
Hardware specifications will vary greatly between institutions.
Some factors to consider include the number of applications that do database lookups, the number of users who make database queries, and the number of users who will use remote desktop sessions.
MnSCU currently runs CAP servers with 3x300Mhz CPU’s (Internal Audit), 2x1GHz CPU’s (Data Extracts).
It may also be useful to note that CAP servers do not necessarily
have to run on server-class (i.e., rack-mountable) hardware. Institutions may want to set up initial CAP servers using available hardware and upgrade later if needed.
CAP Server Access Procedure
In order for MnSCU ITS to open Oracle access for a CAP
server we need information on the CAP server's security setup.
Once we receive that information we will contact the institution to
verify the information or suggest changes. Once the setup has been received and approved, access will be opened through the firewall.
What information do we need?
Prior to opening up access to REPL production we will need the following:
- Assurance that the network that the server is located on
meets MnSCU network security standards (currently in DRAFT status). This requires that the network be layer-3 separated from any desktop networks, and that there be access controls in place between that network and any other network. - Assurance that the CAP server is installed and hardened according to either the Information Security Standards and Guidelines or another reasonable guideline (SANS, NIST),
and that the hardening process and steps are documented. - Assurance that the CAP server has systematic AV and O/S software updating and patching.
- Assurance that the CAP server have role based file system security for all file systems.
- That the CAP server have DNS 'A' and 'PTR' records.
- Approval of Application Manager (Tim Meath or Gerry Rushenberg).
How do we know the campus meets the above?
We rely on:
- A statement from the campus describing 1-4 above.
- A logical (Layer-3) network map or a description in the
case of simple networks. - A statement from campus describing access control policy
on the server network (we do not need the details, just the general statement.)
How do we open up access?
- Before requesting access to REPL, the campus should make sure that all other CAP server communications work. For example: user access to the CAP server, anti-virus updates, patch updates, and other CAP server functionality should all be working before REPL access is requested. This testing should be done with network access controls in place.
- The application owner should send e-mail to hostmaster@mnscu.edu with the above information attached. Network and security staff will review the documentation.
- The application owner should then modify the internal
document at RareSecurity with campus, host, IP, campus contact, and date. - Network staff will edit the firewall object 'RARE_Prod_Campus_Hosts' and reply to the e-mail.
Steering Committee
