SHIFT

--- Sjoerd Hooft's InFormation Technology ---

User Tools

Site Tools


Sidebar

Sponsor:

Would you like to sponsor this site?
Or buy me a beer?:


Recently Changed Pages:

View All Pages
View All Q Pages


View All Tags


Sign up for Q to post comments.





WIKI Disclaimer: As with most other things on the Internet, the content on this wiki is not supported. It was contributed by me and is published “as is”. It has worked for me, and might work for you.
Also note that any view or statement expressed anywhere on this site are strictly mine and not the opinions or views of my employer.


Terms And Conditions for Q users


Pages with comments

PageDateDiscussionTags
2018/07/31 23:30 2 Comments
2017/04/20 16:35 1 Comment
2017/04/20 15:28 1 Comment
2017/04/20 15:23 1 Comment
2017/04/19 14:59 1 Comment
2017/04/19 14:45 3 Comments
2017/04/19 14:44 1 Comment
2017/04/17 20:10 1 Comment
2017/04/17 20:07 1 Comment
2017/04/17 19:58 1 Comment
2017/04/17 19:52 1 Comment

View All Comments

securitylayers

Security Layers

Introduction

This article explains the authentication infrastructure for system administrators of WARMETAL BV. Throughout this document the terms 'users', 'sysadmins' and 'system administrators' are all used referring to logged-on persons maintaining the infrastructure and applications for this environment.

Authentication is divided into layers:
Layer 1: Central administration
The first layer of authentication and security is created by a central point of administration for user accounts and passwords. The directory to provide this central point will be Microsoft's Active Directory. There will be one domain with two domain controllers, one in production, and one in acceptation.
Layer 2: Group Membership
Before you can logon to a server or appliance you have to be member of a security group in Active Directory.
Layer 3: Sudo & UAC
System administrators will do their normal system administration work as normal users. Only when necessary they will maintain administrative rights for executing specific commands or programs.
Layer 4: Emergency access
It will not be possible to logon remotely to a system as an administrative user, to prevent working around the first three security layers.

Overview

This is an overview of the authentication infrastructure:
securitylayersoverview.jpg

Layer 1: Central administration

The first layer of authentication and security is created by a central point of administration for user accounts and passwords. The directory to provide this central point will be Microsoft's Active Directory. There will be one domain with two domain controllers, one in production, and one in acceptation.
User accounts will be created in an organizational unit resembling their service or organization. User accounts will be personal and unique in the domain. Passwords will have to be compliant by password complexity rules which can be different for internal and external users.
Users can only be granted access through these accounts, and the accounts will be used with each operating system and or appliance where possible. Users can also be denied access through these accounts, when they don't need access to systems anymore.
This gives the advantage that users, internal as well as external, only need to know one password. Also, since there is only one account, by disabling this account the user is effectively locked out of every system in the environment.
The only exception on this is the Storage SAN. Beside the lack of an option for enabling central administration for accounts, there is only one account for the system with full privileges. Therefore, external users will never be granted access to the Storage.

Layer 2: Group Membership

Before you can logon to a server or appliance you have to be member of a security group in Active Directory.
Beside accounts there will also be global security groups in Active Directory, each representing a system or appliance inside the environment. Users who need access to specific systems will be made member of the group representing the system. When the user is a member of the group, and the account is not disabled they can logon to the system. When one of those requirements is not met, they will be denied access.
The advantage is that users can obtain or lose access to systems by their memberships, thus obtaining a second layer of security.

Note: Group membership is a cached LDAP attribute. This means that gaining or loosing access to systems can be delayed with a maximum of 10 minutes. In case of emergency this can be bypassed by shutting down the cache daemon until the 10 minutes are passed.

Layer 3: Sudo & UAC

System administrators will do their normal system administration work as normal users. Only when necessary they will maintain administrative rights for executing specific commands or programs.
During normal work routine users do not have the rights to make changes to settings, services and programs on a system. They don't need supervisor access to check most logfiles, monitoring data and processes. Only when necessary they will be allowed to execute programs or commands using other privileges than their own. This can be as an application user or as an administrative user (for example root).
On unix based systems this will be achieved by listing allowed 'run as' and corresponding commands in the sudo configuration, which creates a third layer of security. Using sudo will also log the commands and routines to the central syslog server, creating the possibility for supervising the use of extended privileges.
On Windows based systems User Access Control will be used to warn system administrators that they are about to change system settings. This is not an extra security layer so these systems will not be made available to external users.
On network appliances there is no way of implementing a third level of security, or even a warning system. Network appliances will for that reason not be made available to external users.

Sudo Implementation

External users requesting access to the unix based systems (which are the only systems they can request access to) have to provide a list of commands they need to run under which user account and why. The purpose of this list is that it can be checked by the company's security officer and internal system administrators to prevent abuse and gaining more privileges than required. For example, shell access as root is never required, while sqlplus access as the applicationuser might be required for database administrators.
For internal system administrators there will be two default groups, INFRA, for the system administrators, and TAM, for the application administrators.

Layer 4: Emergency access

It will not be possible to logon remotely to a system as an administrative user (except network appliances and the storage), to prevent working around the first three security layers.
However, when a disruption occurs of the authentication services users will also be denied access, thus locking them out and preventing them from fixing problems. To prevent this lockout, administrative access will be allowed from the console.
This means that for the different type of systems different type of security measures must be taken:

  • In case of physical systems system administrators will need physical access to the systems as well, or will need access by means of hardware access cards (for example iLo).
  • In case of network appliances a system administrator will also need physical access to the device.
  • In case of VMware virtuals system administrators need access to the Virtual Center console using the local system administrator.
  • In case of blades system administrators need access to the remote console option in the bladecenter using the local supervisor account.

To make this layer effective the passwords for the local accounts need to be hardened and maintained by a security officer as well as access to the rooms where the systems are located.

You could leave a comment if you were logged in.
securitylayers.txt · Last modified: 2013/03/08 05:15 by sjoerd