SSH was designed in 1995, LDAP was initially developed in 1993, and role-based access control was introduced in 1992. The concept of least privilege was introduced in 1975. With all of these existing technologies, when are modern privileged access management solutions necessary? This is a common question asked when we pitch the idea of modern privileged access management (PAM).

The SSH protocol offers multiple authentication options: passwords, public keys and certificates. Certificate-based authentication is the most secure of them all, but historically, it has been the most complicated to set up. This tutorial guides you through simple steps to configure certificate-based authentication for an OpenSSH server. First, let's consider the differences between certificates and keys. As you can see, an SSH key is a binary proposition.

The modern human likely has profiles on dozens of applications. Whether it’s social media applications, music/video streaming, or workspace resources, each of us must manage accounts that contain personal information. Over time, these siloed applications have become increasingly connected. Twitter allows news sites to directly tweet, Discord searches Facebook for suggested friends, and Jira creates user accounts using Github profiles.

Kubernetes supports several authorization methods, but the best-known and one of the most versatile is RBAC. Role-based access control implements a mechanism for restricting and controlling user access to resources of a system by using roles attached to users.

Many businesses use virtual private networks (VPNs) to provide secure remote access to their systems, but this has increasingly become a liability as more people switch to remote work. The greater demands placed on VPNs to offer safe access can expose organizations and employees to security vulnerabilities. In order to better protect their data and systems, organizations may need to seek alternatives to VPNs.

This blog is Part IV in a series about identity-based access management of AWS resources. In Part I, we covered how to use OSS Teleport to access Amazon EC2 instances running in private subnets. Part II explained implementing identity-based access via SSO integration with Okta. Part III covered the steps to configure privilege escalation for just-in-time access requests. In Part IV, we will guide you through the steps to configure SSH session recording and auditing.

As part of our Teleport 9 release, we added support for three more databases: Redis, MariaDB, and Microsoft SQL Server. In this post we’ll cover the steps needed to protect your Redis instance using Teleport Database Access. Teleport Database Access allows you to easily secure your databases using security best practices such as identity-based SSO, short-lived certificates for engineers or service accounts, multi-factor authentication, RBAC, and audit of all access and queries.