← Policies

User Access

Operating System Access

Authorized Users

Infrastructure team members (Dobby, Lakitu and Pulsar) are authorized to access servers directly to fulfill their job functions. Launch Control members are granted access to Banno Content load balancers to fullfill their job function. No other users are authorized for direct access to the operating system.

Authorized users are defined in the Cookbooks version controlled repository on github. Any changes require approval to be merged and approval to be deployed.

Firefighter

Temporary elevated access to datastores can be granted to developers to fullfill their job functions. A request must be submitted within the public #org-techops slack channel, approval is granted to all developers, a member of Pulsar or Ground Control will login to https://banno.com/a/login to grant access. The Banno People platform logs these events and they are aggregated to and archived in our logging platform. Access expires after 1 week and is purged every Monday by a member of Pulsar or Ground Control.

Specifically “Firefighter access” is a group on banno platform that users can be assigned. It gives all of the admin permissions that a group can have turned on (visible in that link). These permissions are for all institutions and include.

  • Activity - View employee events
  • Monitor - Manage monitors
  • Users - View/Edit/Invite/Delete
  • Groups - View/Edit/Create/Delete

Logging

All OS user logins and actions on servers that require elevated permissions (i.e. using sudo) are captured by the kernel and sent along to the corporate SIEM (Splunk) via syslog. These events are filtered for fradulent behavior by JHA Cybersecurity. A dashboard is emailed to the Banno Security team daily via BannoSecurityTeam@jackhenry.com. This is reviewed daily and any suspicious activity is brought up to the Banno Security team to determine impact and next actions.

Review

A review will be done during each quarter of the year. Quarters run the following date ranges; Q1 January-March, Q2 April-June, Q3 July-September, October-December.

The infrastructure team will provide GitHub issues evidencing the current OS access, datastore privileges, and user accounts controlling access to internal systems used by Jack Henry employees.

Post-review

If the review finds an account with unauthorized access the reviewer will communicate with the user granted the access prior to removing the access. The unauthorized access event will be reviewed in the next upcoming Security Team meeting to determine impact. If necessary management will be notified of the impact.

OS User Access to implement changes

Provisioning

All systems are built off a hardened base image. During build the SSH service is configured by the build script image.sh to disable password based authentication and enable only RSA/PublicKey based authentication. A default user bannoadmin and associated ssh keypair is generated and used during the initial install. This account can only be logged into during the initial provision at which point it locks the account. Once the ssh keypair is generated local console access is disabled. After the install and during first launch a post-install script automatically adds a list of users to the sudoers(privileged users) config.After administrative users have been added the bannoadmin authorized_key is removed from the system effectively disabling remote access for the banno user.

Post Provisioning

Once initial provisioning is complete user management is controlled by the banno-users cookbook maintained on github. Changes are pushed out to systems with a chef push. Github repositories maintain a revision history for every file committed and this would be where we would reference the current and past state of systems.
Base image details User Cookbook Technical Note

  • In the cookbook the :create, :lock users are users that had access at one time and now have been locked out

Database Access

Access is authenticated using github team membership, upon successful authentication a token is generated that grants a user rights to perform specific actions for a predetermined amount of time. The environments repo contains the state definition of all systems; part of which is the Vault configuration and policies. These policies outline the permissions granted to a github team and the list of postgres database servers using the policy(role).

environments/shared/vault/policies/<team name>/policy.hcl The policy.hcl outlines the permissions for the team and determines rights to be given to the locations referenced inside vault.

Production Environment Definition
Role Example

A detailed outline of Vault Policies

Github.com/Banno/operations/scripts/pg-role-audit.sh will login to each of our Postgres DB servers and query the current roles applied to the DB. Only members of Infrastructure/Operations can run this report.

./pg_role_audit.sh ~/projects/src/github.com/Banno/operations/

A list of all pg servers and roles is output and then aggregated into all.txt