Infrastructure Policy

All production infrastructure must follow this policy.

 

1. Accountability 

Accountability to ensure our infrastructure is secure and is following this policy is of “Infrastructure Manager”. Any exception to this policy must have prior approval from the Technology Director. All granted exceptions must be saved and maintained for future references.

 

1. Control Requirement

   1. Review 

      1. Technology director must review, at minimum quarterly, all infrastructure activities performed by the Infrastructure manager, ensure that its use is as per this policy.

      2. Infrastructure manager, at minimum monthly, must review all infrastructure activities performed by members of its team (server/database admins) and ensure that its use is as per this policy. 

      3. Server Admins, at minimum bi-weekly, must review all server activities performed by accounts that are not part of the “server admin” team and ensure that its use is as per this policy. 

      4. Database Admins, at minimum bi-weekly, must review all database activities performed by accounts that are not part of the “database admin” team for all production databases and ensure that its use is as per this policy. 

   2. Report

      1. Any unauthorized/suspicious activity must be reported to the “Technology Director” as soon as possible.

      2. A ticket must be opened by the person identifying the issue and assign it to the technology director.

      3. An email must be sent to the Technology directory with the ticket details to report the issue.

   3. Resolution

      1. After unauthorized/suspicious activity is reported to the Technology Director, it must take appropriate action within 15 working days -

         1. The action might involve assigning people/team to investigate the issue and determine root cause, damage done and recommendations to mitigate the damage.

         2. Review the result of the investigation with “Business Director”.

         3. Request appropriate action -

            1. From the Business Director to communicate with the client if client data was compromised.

            2. From Infrastructure manager to mitigate damage and adjust procedures to avoid the root cause in the future.

 

1. Audit Requirement

   1. For audit purposes, all infrastructure work must always be performed only after an approved and authorized request. This can be either a Jira item or a support ticket.

   2. This request for infrastructure services must be initiated by the user needing infrastructure services and support and approved by Infrastructure Manager.

   3. Defined SLAs must be established for Infrastructure tickets and the Infrastructure manager must ensure completion of infrastructure tickets as per the agreed SLAs.

   4. Infrastructure manager must schedule bi-weekly production review meetings to review all production activities with the Technology Director. This at minimum must include -

      1. Production Deployments

      2. Production Outages

      3. SLA tracking 

 

1. Infrastructure Policy

   1. Servers

      1. All production servers must use the open source operating system CentOS.

      2. A standard, common and consistent OS version across all production servers must be used as per norms established by the Infrastructure manager. 

      3. At no time any production server should use CentOS operating system major version that has a release date of  

         1. More than 10 years.

         2. Less than 2 years.

      4. All production servers must be updated with any security patch issued by CentOS within 2 weeks of release. 

   2. Server Operations

      1. Infrastructure manager must designate a “server admin” role and assign this role to a member of its team (or himself).

      2. While creating servers, the “server admin” must ensure to add its public key while creating new servers. This will ensure that only “server admin” can remote login as root after the server is created.

      3. After logging in for the first time “server admin” must 

         1. Change the root password and email this password to Infrastructure Manager. 

         2. On receiving this email, the Infrastructure manager must change the root password and maintain it safely. Any activities performed on the server by root id going forward will be considered to be performed by the Infrastructure Manager. 

         3. If the Infrastructure manager has to provide the root password to a “server admin” for activities that can not be performed by the “server admin” using sudo access then after the work is completed by the “server admin”, Infrastructure manager must change the root password and maintain the new password safely.

      4. Immediately after creating the server “server admin” must remote login as root and create an account for itself (example johndoe) using its public key again and give this account sudo access. 

      5. No user must be allowed to remote login into production servers using a root account, except first time during server creation, and instead use its own account (johndoe) to remote log in to production server. If higher privileges are required then it should use sudo access to achieve those tasks. root user id must only be used in case of emergencies and a user must switch account (su) into the root account after remote logging in as itself first. In order to do this, “server admin” must -

         1. Create a new group called “svayam” and its own account (johndoe) to this group

         2. Modify /etc/ssh/sshd_config to  

            1. Disable password login (PasswordAuthentication no)

            2. Disable Public Key Authentication ( PubkeyAuthentication no )

            3. Disable Root Login (PermitRootLogin no  )

            4. Set Inactivity time to 5 mins ( LoginGraceTime 5m )

            5. Allow only those users that are part of group svayam to login using public key based authentication (Match Group svayam PubkeyAuthentication yes )

            6. Restart SSH daemon for these changes to take effect.

      6. Only authorized users who request access to a production server using support tickets that are approved by the Infrastructure Manager should be allowed to remote login to production servers. In order to do this -

         1. Users needing access to production servers must provide their public key to the “server admin” as part of the account opening request ticket. 

         2. “server admin” should create the requested account and then add the user's public key to the “authorized_key” file for remote login. 

         3. “server admin” must add this user to group svayam so that they can remote login using their private key. 

         4. Only users that are assigned to the “server admin” role must be part of group svayam at all times. This will ensure that only server admins will be able to remote login to production servers. 

         5. If any other user needs to remote login to the production server for some authorized work then they can be added to the group svayam temporarily but after the work is completed then this user should be removed from the svayam group so that he can’t remote login after work is finished.

         6. Every user is accountable for protecting their private key. For any access and subsequent activity using a user’s private key as recorded in logs will be assumed to be performed by that user only.

      7. Irrespective of whether a user is able to remote connect to a production server or not, only “server admins” can be added to the sudo group. Any activity requiring sudo privileges must be performed by server admin. After a “server admin” leaves or is reassigned, its account must be removed from sudo and svayam groups.

      8. Server Logs and Monitoring

         1. Server admin must maintain and backup following logs from the server.

            1. /var/log/message – Where whole system logs or current activity logs are available.

            2. /var/log/auth.log – Authentication logs.

            3. /var/log/kern.log – Kernel logs.

            4. /var/log/cron.log – Crond logs (cron job).

            5. /var/log/maillog – Mail server logs.

            6. /var/log/boot.log – System boot log.

            7. /var/log/mysqld.log – MySQL database server log file.

            8. /var/log/secure – Authentication log.

            9. /var/log/utmp or /var/log/wtmp : Login records file.

            10. /var/log/yum.log: Yum log files.

         2. Monitor and audit user activity regularly. (https://www.tecmint.com/how-to-monitor-user-activity-with-psacct-or-acct-tools/)

         3. Adopt best practices for server administration. (https://www.tecmint.com/linux-server-hardening-security-tips/)

         4.  User security audit and scanning tools. 

            1. https://www.tecmint.com/linux-security-auditing-and-scanning-with-lynis-tool/

            2. https://www.tecmint.com/nmap-network-security-scanner-in-kali-linux/

      9. Production servers must always have backup enabled. This is an option that is available at the time of creating a server. For existing production servers we must find ways to enable this. If it can’t be done then we should plan migrating to a new server with backup enabled.

 

1. Perimeter Security

   1. All production servers must be behind a firewall.

   2. All production servers must only allow key based login. Password logins must be disabled.

   3. By default only SSH port (22) should be open on production servers.

   4. In addition to a SSH port, other ports that are specifically requested by the service, product or development manager as part of their deployment request can be opened.

   5. In addition to ports required in step c and step d, no other port must be open for anyone including developers for direct access. Specifically database ports must never be open for direct access.

Example -

 

1. Communication Security

   1. All communications from/to production servers such as web traffic must be encrypted using TLS1.3 certificates.

   2. All communications between production servers can be unencrypted as long as all the servers that need to communicate are within the same firewall zone.

 

1. Database Policy

   1. Database Server 

      1. A standard, common and consistent database and its major version must be used for all production databases installed in production. Infrastructure manager must define and adjust this standard according to following guidance -  

         1. All production databases must be open source and either MariaDB or PostgreSQL. In case a need arises in the future to use other types of databases such as nosql mongodb, big data HIVE/HBASE etc in production then it will be raised as an architectural requirement and appropriate policy changes will be added to this document.

         2. Any database being used in production can never use an unsupported version for which security patches are no longer being issued. 

      2. No production database used in our solutions will allow connections from clients outside the firewall. In case a need for this arises in future then it will be raised as an architectural requirement and appropriate policy changes for securing (encrypted) connections by clients outside firewall will be added to this document.

      3. All database installs must be performed by “server admin” roles only. 

         1. Server admin must always use secure installation methods (example mysql_secure_installation for mysql) and must change the database’s default root password to a new password. 

         2. After installation of a database a default database administration user id, for example mysql or pgsql, is created in the system. “server admin” must change the default password for this user id to a new password.

         3. “server admin” must email passwords of (a) database administration user id (eg mysql) and (b) database’s root account to “Infrastructure Manager”.

 

1. Database Operations

   1. Infrastructure manager must designate a “database admin” role and assign this role to a member of its team (or himself).

   2. After receiving database administration user id (eg mysql) from “server admin”, Infrastructure manager must - 

      1. change passwords for (a) database administration user id (eg mysql) after receiving them from “server admin” and maintain it securely. 

      2. He should provide this password to “database admin” that he assigns to perform the “database admin” roles.

      3. He should change this password when a “database admin” leaves or is reassigned. 

   3. After receiving database root account password from “server admin”, Infrastructure manager must - 

      1. Use the database root account to log into the database and create a new account, for example johndoe, and grant it all accesses required for database administration purposes. 

      2. Provide the password for this account to the user “John Use'' who has been assigned to the “database admin” role. 

      3. Revoke the database account of the user who leaves or is reassigned in the database.

      4. Database’s root account must never be used by anyone else except Infrastructure Manager. 

      5. Infrastructure Manager should use the database's root account only for granting/revoking database admin privileges to/from user accounts belonging to users assigned to  “database admin” roles and nothing else.

   4. A “database admin” must always use database administration user id (eg mysql) for server related database administration activities.

   5. All users including “database admin” must change their database account password after receiving it from the Infrastructure team. This can be done -

      1. MYSQL : SET PASSWORD = PASSWORD('passwordString');

      2. POSTGRES: ALTER USER <user> PASSWORD '<pass>';

   6. All users including “database admin” must protect their database account password and never share with any other user. All database activities performed using a database account will be considered to be performed by the user of that account itself. should not allow.

   7. All database accounts created for applications (no-user accounts) -

      1. Must be protected by the “database admin” and once these accounts are created then their passwords must never be disclosed to anyone. 

      2. Must have their password stored in an environment (nodejs) /configuration file (jdbc) that is readable by respective application user accounts only. The path of these environment and configuration files must be provided to the application owner (service/solution/development manager). Preventing unauthorized access of application accounts is the responsibility of the Infrastructure Manager. 

      3. All correctly authorized activities performed by application accounts will be the responsibility of their respective application owner (service / solution / development manager). 

      4. Application accounts that need access to the database must specify - 

         1. Host from where they will be connecting to the database (these hosts must be within the same firewall zone)

         2. Database account id that they would like to use in their application

         3. Access that they would like to be granted for this database account

      5. Applications must use the environment (nodejs) or configuration (jdbc) file to get the right credentials to login and create connections with desired databases. 

   8. Databases must be backed regularly, at least once a day, by default. More frequent backups must be specifically requested by application owners.