Skip to content

ssh notes for design changes #58

@BradleyA

Description

@BradleyA

Notes about SSH keys in your organization

1 How many SSH keys is your organization using?
2 How many systems they can access?
3 Who uses them?
4 When were they last changed?
5 Do you have a complete list for audits?
6 Where are your SSH keys located?
7 How much access are they providing?
8 Who can use them?
9 Do you limit SSH keys use by location? SSH configurations can restrict the locations from which each authorized SSH key can be used. When access is limited to the known locations of administrators and machine to machine access, it prevents malicious access from other locations.
10 Do you rotate your organization SSH user keys?
11 Who controls the SSH keys at your organization? (key master, key master backup persons)

==>
Your organization ends up with thousands of SSH keys that provide access to mission critical systems - all without reviews, rotations, or policy enforcement.
Did one of your administrators enable port forwarding on an SSH connection that is approved to traverse through one of your firewalls? This administrative loophole can allow ATT hackers to bypass firewalls.

User configuration of their own authorized SSH keys
When you allow user/administrators to control SSH privileged access and when to update keys, you end up with inconsistent security controls, or worse, a compromise of privileged systems or data.

It is time to prioritize SSH management and security using a centralized, automated (?) approach

4 Steps to SSH Security
Sound security, policy and auditing practices for
SSH keys are required to secure SSH environments.
The following four steps will help secure your
organization’s SSH usage:

  1. Build a comprehensive inventory. For
    SSH visibility and control across the network,
    organizations need centralized visibility into
    all SSH servers, private keys (the authorized
    keys that grant SSH access) and any SSH
    configurations that limit access.
  2. Identify vulnerabilities. To reduce the risk of
    breach and compromise, organizations must be

Metadata

Metadata

Assignees

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions