Use of Central Authorisation Service Code of Practice Introduction This code of practice is intended to support the Information Security Policy of the University and should be read in conjunction with this document. http://www.ed.ac.uk/schools-departments/information-services/about/policiesandregulations/security-policies/security-policy This code of practice is also qualified by The University of Edinburgh computing regulations, found at: http://www.ed.ac.uk/schools-departments/information-services/about/policies-and-regulations 1. Code of Practice Version Revision Date CoP Template Author Notes Version Version 25 th January 1.0 1.4 Graeme Wood Initial draft 2012 04/09/12 1.1 1.4 Tony Weir Minor edit 04/09/12 1.2 1.4 Graeme Wood Minor edit 29/9/14 1.3 1.4 Graeme Wood Minor edit 6/11/14 1.4 1.4 Graeme Wood Minor edit QA Date QA Process Notes 15 Dec 2014 ITC Sec Working Gp Suggested date for Revision of the CoP January 2014 January 2016 Author Graeme Wood Graeme Wood 2. System description Revision Date System Author Notes Version N/a N/a N/a N/a Use of Central Authorisation Service Code of Practice 1
2.1 System name Central Authorisation Service. May also be known as central auth or cauth. 2.2 Description of system The service is an LDAP directory containing information about identities and the access rights they may have to other services. 2.3 Data The directory contains information fed to it from the Identity Management Service about identities and group information from Grouper. These include university usernames and associated data about their place within the university hierarchy, email address, Unix UID, full name, identity category e.g. staff/student/alumnus/visitor, entitlements to services and group memberships. 2.4 Components The service comprises four replicated LDAP directory servers and two replicated Identity Management System connector systems to feed data from the IDM into the directory. 2.5 System owner Information Services ITI Unix Section 2.6 User base Any user identity in the university, i.e. anyone with an assigned university username and password, can query the directory for information. The data may also be queried programmatically to enable authorisation decisions for access to services based on the information in the directory e.g. apache LDAP group authorisation to web pages. 2.7 Criticality High 2.8 Disaster recovery status A disaster recovery plan is not in place since the service is highly resilient and replicated on multiple servers across multiple sites. Schools are recommended to create their own local replicas for greater resiliency. Use of Central Authorisation Service Code of Practice 2
3. User responsibilities 3.1 Data Data provided by the central authorisation service should not be made accessible to anyone outside the university or contracted university service providers. The data comprises personal data and is protected by the Data Protection Act and data protection policies of the University. 3.2 Usernames and passwords Off-site access to the service is protected by University Username and EASE password. 3.3 Physical security The servers are located within secure data centres operated by Information Services. 3.4 Remote/mobile working Data extracted from the LDAP directory by an authenticated remote user should not be republished or made available to any non-member of the University unless contracted by the University to provide a service on its behalf. Users should protect any device that may use the LDAP directory with suitable locks or password protection and 3.5 Downloads and removal of data from premises 3.6 Authorisation and access control maintain physical security of their equipment. Data downloaded from the LDAP directory should be protected, since it contains personal data, and should not be made available to any non-member of the university unless contracted by the University to provide a service on its behalf. All University users have read access to the data. System administrative access is granted to members of the Information Services ITI Unix Section and defined by their membership of that team and being granted specific login access to the servers. 3.7 Competencies No special knowledge is required for people to securely access the service. Knowledge of how to construct LDAP queries and the directory schema are required in order to use the service. Information to assist users is published on the University Website and the Central Authorisation Service wiki pages. Use of Central Authorisation Service Code of Practice 3
4. System Owner Responsibilities 4.1 Competencies The ITI Unix Section has members of staff with many years of experience in managing Unix services and LDAP directories on Unix. They are highly skilled at maintaining such systems and identifying potential security issues. 4.2 Operations The systems are regularly maintained through a patch regime. Security incident sites are monitored proactively. The service undergoes regular hardware refresh cycle over 4 to 5 years to ensure all components are kept up to date 4.3 System documentation End user documentation is provided on the IS section of theuniversity Website and the Central Authorisation Service wiki. Operational and system documentation is on the ITI Unix Section wiki. 4.4 Segregation of Duties ITI Unix Section staff have full login access controlled by EASE login to the servers running the service. No other user has access to the physical servers. All other access is through LDAP queries to the directory, which may require authentication for off-site access, or to update data. 4.5 Security incidents All security incidents are reported to the IS IRT team and are logged and handled by them. The ITI Unix Section will then review the incident/logs and depending on the nature of the incident take appropriate action and report back to IRT. 4.6 Fault/problem reporting 4.7 Systems development Security incidents are reported to the ITI Unix Section head, who will inform the ITI Director as appropriate. Faults and problems should be reported to the IS Helpline who would then escalate to 2nd and 3rd line support if necessary. Systems development takes place within the IS Unix Section on test and development systems before live deployment. The software stack used for the services makes use of open-source packages and th e appropriate community channels for support are used and contributed to as appropriate. Use of Central Authorisation Service Code of Practice 4
5. System Management 5.1 User account management User accounts on the physical servers are only provided to IS ITI Unix Section staff. These are maintained manually. 5.2 Access control Access control is maintained using access control lists defined within the directory itself. This limits unauthenticated lookups to the University network for instance and write access to specific users and systems. 5.3 Access monitoring Access logs are maintained on the servers to ensure the correct operation of the service and the service security. 5.4 Change control Change management is organised through ITI Unix Section service management procedures for significant changes to the service. Major outages to the service to put in place such changes are signed off by reference to the Helpline and Operations teams in IS User Services division and to the Applications Division. Minor changes are normally carried out as a request to fix a fault resulting from an incident or change request and are signed off by the ITI Unix Section service manager. 5.5 Systems clock synchronisation All servers synchronise their clocks to UTC using the NTP protocol. 5.6 Network management The servers are behind the university's Cisco FWSM firewall that is managed by ITI Network Section. Additionally the servers implement their own IP access controls to limit access to services running on the servers. 5.7 Business continuity The service is replicated across multiple servers in three locations over two sites. This is intended to be extended to a third site. Schools are also encouraged to replicate the directory data to directory servers within their schools. 5.8 Security Control The LDAP directory provides a mechanism of ACLs within itself to authorise access to the data. This can be used to restrict access to particular data attributes to specific accounts or IP addresses. Use of Central Authorisation Service Code of Practice 5
6. Third Party 6.1 Outsourcing Not applicable. 6.2 Contracts and Agreements 6.3 Compliance with the university security policy Support contracts are in place for the hardware and operating system of the servers. Occasionally engineers from the hardware supplier may come onsite to enact repairs. Components that may contain University data e.g. hard disks, that are replaced are securely handled and data is destroyed securely. The agreements comply with the university's scurity policy. 6.4 Personal data No personal data is provided to third-parties for the purposes of providing or maintaining the service. However, University service partners contracted to provide services to the University may be provided monitored access to the service in order to provide their contracted services. Use of Central Authorisation Service Code of Practice 6