Identity-Native Infrastructure Access Management Preventing Breaches by Eliminating Secrets and Adopting Zero Trust (Ev Kontsevoy, Sakshyam Shah, Peter Conrad) (z-library.sk, 1lib.sk, z-lib.sk)

SECURIT Y “Identity-native infrastructure access has emerged as the key to conquering complexity. With each chapter of this book, the four pillars of access—connectivity, authentication, authorization, and audit—echo louder, redefining our understanding of safeguarding tomorrow’s infrastructure.” —Prabath Siriwardena Engineer (Identity), DevRev Identity-Native Infrastructure Access Management Twitter: @oreillymedia linkedin.com/company/oreilly-media youtube.com/oreillymedia Traditional secret-based access management can’t scale to meet the complexity and growth of cloud and on-premises infrastructure. Today’s applications are spread across a diverse range of clouds and colocation facilities as well as on-prem data centers—and each layer of this modern stack has its own attack vectors and protocols to consider. How can you secure access to diverse infrastructure components, from bare metal to ephemeral containers, consistently and simply? In this practical book, authors Ev Kontsevoy, Sakshyam Shah, and Peter Conrad break this topic down into manageable pieces. You’ll discover how different parts of the approach fit together so that engineering teams can build more secure applications without slowing down productivity. You’ll learn: • The four pillars of access: connectivity, authentication, authorization, and audit • Why every attack follows the same pattern, and how to make this threat impossible • How to implement identity-based access across your infrastructure for humans and machines • Why it’s time for secret-based credentials to go away • How to break access silos and manage permissions across different computing resources • How to design infrastructure access to accommodate scaling of hardware, software, and teams Ev Kontsevoy is cofounder and CEO of Teleport. Sakshyam Shah is a cybersecurity architect and engineer at Teleport. Peter Conrad is an author, artist, and technical content strategist. US $45.99 CAN $57.99 ISBN: 978-1-098-13189-0

Ev Kontsevoy, Sakshyam Shah, and Peter Conrad Identity-Native Infrastructure Access Management Preventing Breaches by Eliminating Secrets and Adopting Zero Trust Boston Farnham Sebastopol TokyoBeijing

978-1-098-13189-0 [LSI] Identity-Native Infrastructure Access Management by Ev Kontsevoy, Sakshyam Shah, and Peter Conrad Copyright © 2023 O’Reilly Media, Inc. All rights reserved. Printed in the United States of America. Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472. O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (http://oreilly.com). For more information, contact our corporate/institutional sales department: 800-998-9938 or corporate@oreilly.com. Acquisitions Editor: Jennifer Pollock Development Editor: Jeff Bleiel Production Editor: Aleeya Rahman Copyeditor: nSight, Inc. Proofreader: Heather Walley Indexer: Ellen Troutman-Zaig Interior Designer: David Futato Cover Designer: Karen Montgomery Illustrator: Kate Dullea September 2023: First Edition Revision History for the First Edition 2023-09-12: First Release See http://oreilly.com/catalog/errata.csp?isbn=9781098131890 for release details. The O’Reilly logo is a registered trademark of O’Reilly Media, Inc. Identity-Native Infrastructure Access Management, the cover image, and related trade dress are trademarks of O’Reilly Media, Inc. The views expressed in this work are those of the authors and do not represent the publisher’s views. While the publisher and the authors have used good faith efforts to ensure that the information and instructions contained in this work are accurate, the publisher and the authors disclaim all responsibility for errors or omissions, including without limitation responsibility for damages resulting from the use of or reliance on this work. Use of the information and instructions contained in this work is at your own risk. If any code samples or other technology this work contains or describes is subject to open source licenses or the intellectual property rights of others, it is your responsibility to ensure that your use thereof complies with such licenses and/or rights. This work is part of a collaboration between O’Reilly and Teleport. See our statement of editorial independence.

Table of Contents Preface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii 1. Introduction: The Pillars of Access. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Most Attacks Are the Same 2 Access 5 Secure Connectivity 5 Authentication 6 Authorization 7 Audit 7 Security Versus Convenience 8 Scaling Hardware, Software, and Peopleware 9 Identity-Native Infrastructure Access 12 2. Identity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Identity and Access Management 17 Identity and Credentials 18 Traditional Approaches to Access 18 Identity-Based Credentials 22 Establishing Trust in Identity 23 Identities in Infrastructure 25 Long-Lived Identities 26 Ephemeral Identities 27 Identity-Native Access 28 Identity Storage 28 Identity Attestation 29 Reducing the Number of Secrets to One 33 A Path to Identity-Native Infrastructure Access 34 Eliminate Access Silos 34 iii

Move to Certificates for Identity Proofing 34 Extend Identity-Native Access to Service Accounts 35 3. Secure Connectivity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Cryptography 37 One-Way Functions and Hashing 38 Symmetric Encryption 39 Asymmetric Encryption 41 Certificates as Public Keys 43 The Untrusted Network 45 Encrypted and Authenticated Connectivity 45 Moving Up in the Networking Stack 47 Perimeterless Networking for North-South Traffic 48 Microsegmentation for East-West Traffic 49 Unifying the Infrastructure Connectivity Layer 50 Secure Connectivity and Zero Trust 50 4. Authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Evaluating Authentication Methods 54 Robustness 54 Ubiquity 55 Scalability 55 Secret-Based Authentication 56 Public Key Authentication 58 Certificate-Based Authentication 60 Multifactor Authentication 63 Single Sign-On 64 How SSO Works 64 Beyond Traditional SSO 66 Identity-Native Authentication 66 Identity Proofing 67 Device Attestation 68 WebAuthn 69 Authenticating Machines 69 Preserving Identity Postauthentication 70 5. Authorization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Infrastructure Protects Data 72 Types of Authorization 72 Discretionary Access Control 73 Mandatory Access Control 75 The Bell–LaPadula Model 76 iv | Table of Contents

Multics 78 Mandatory Access Control in Linux 83 Nondiscretionary Access Control 83 Privilege Management 84 Principle of Least Privilege 85 Zero Standing Privilege 86 Just-in-Time Access 86 Dual Authorization 86 Challenges in Authorization 87 Access Silos 87 Privilege Classification 88 Authorization for Machines 89 Complexity and Granularity 89 Identity and Zero Trust 91 Identity First 92 Single Source of Policy Truth 92 Context-Driven Access 92 Identity-Aware Proxy 93 6. Auditing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Types of Logs 97 Audit Logs 97 Session Recordings 99 Logging at Different Layers 99 Host Logging 100 Network Monitoring 103 Log Aggregation 103 Security Information and Event Management (SIEM) 105 Log Schemas 106 Storage Trade-Offs and Techniques 107 Evolution of the Cloud Data Warehouse 108 Log Analysis Techniques 108 Log Analysis Example: Modern Ransomware Attack 109 Auditing and Logging in an Identity-Native System 112 7. Scaling Access: An Example Using Teleport. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 Access at Scale 113 Identity-Native Access Checklist 114 Necessary Components 116 The Teleport Infrastructure Access Platform 118 The Cluster 118 How Teleport Works 119 Table of Contents | v

Managing Users 121 Managing Client Devices 121 Managing Permissions 122 Managing Audit 123 Zero Trust Configuration 123 Living the Principles of Identity-Native Access 124 8. A Call to Action. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 Security and Convenience at Scale 127 The Future of Trust 128 Infrastructure as One Big Machine 129 The Future of Security Threats 129 Closing Words 130 Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 vi | Table of Contents

Preface The challenge of securing infrastructure is no secret. As an organization scales and more people need access, a lush forest of policies and tools grows organically, result‐ ing in both inconvenience and vulnerability across the entire infrastructure. This is very bad. This book provides theory and real-world advice to help organizations step up to the new challenge of securing infrastructure: no secrets! The following chapters consider all aspects of identity-based access management, addressing topics from identity proofing to auditing. By bringing identity-based, unified policy to both humans and machines, this book aims to solve vulnerability and inconvenience in one stroke. After all, the point of infrastructure access is to let the right people in so they can work together easily. Who Should Read This Book As a company grows, infrastructure access becomes more important and more diffi‐ cult. Secret-based perimeter defenses don’t scale. This book is for anyone facing the challenges of defending an ever-growing infrastructure, whether on-premises, in the cloud, or both. The book is accessible to a reader with a modicum of technical skill and a passing familiarity with IT, networking, and the Linux command line. Whether you’re an executive, an IT policymaker, or a DevOps engineer, if you have responsibility for helping secure heterogeneous computing infrastructure, this book is for you. vii

Goals of the Book The world is changing. Infrastructure will continue to evolve. New tools, platforms, and technologies will spring into use alongside legacy products and services. Securing infrastructure will become more and more crucial, but also more difficult. The old approaches don’t work anymore. Without a basis in proven identity, vulnerabilities and friction inevitably develop, leading to increasing cost and a breakdown in trust. This book outlines an approach designed to bring trust back, providing chains of trust and chains of proof that reduce vulnerability and human error while making access policies easier to follow. By rebuilding trust, we aim to make it easier for people to work together securely. In fact, security should be something the average user doesn’t have to think about. Navigating This Book This book begins with the basics of identity-based security, proceeds through the foundations of connectivity, authorization and authentication, then winds up with a real-world example and a call to action. Here are brief descriptions of the chapters: Chapter 1, “Introduction: The Pillars of Access” The weaknesses of traditional security models and how true identity-native infrastructure access solves these problems by eliminating human error and the attacker’s ability to pivot. Chapter 2, “Identity” This chapter defines and discusses identity, the challenge of proving and repre‐ senting identity, and a method for bringing physical identity into the digital realm. Chapter 3, “Secure Connectivity” This is a discussion of the importance of secure connectivity and the principle of zero trust, showing why it is important for identity-native infrastructure access. Chapter 4, “Authentication” We talk about authentication schemes, with an eye toward using existing and new authentication techniques to support the identity-native principles discussed throughout the book. viii | Preface

Chapter 5, “Authorization” Here are a variety of authorization frameworks, showing how they can work together to bring consistent policy enforcement across infrastructure, including bringing data protection to the hardware level. Chapter 6, “Auditing” This explains why auditing is an important complement to identity-native access policy, including an example of a typical attack and how the principles discussed in the book can help defend infrastructure. Chapter 7, “Scaling Access: An Example Using Teleport” Here is a real-world example using Teleport and other open source tools and techniques to implement identity-native infrastructure access policy at scale. Chapter 8, “A Call to Action” This final chapter is a look at the state of the world, a glance forward, and a call to action: How can we create the best possible future for trust in technology? Conventions Used in This Book The following typographical conventions are used in this book: Italic Indicates new terms, URLs, email addresses, filenames, and file extensions. Constant width Used for program listings, as well as within paragraphs to refer to program elements such as variable or function names, databases, data types, environment variables, statements, and keywords. O’Reilly Online Learning For more than 40 years, O’Reilly Media has provided technol‐ ogy and business training, knowledge, and insight to help companies succeed. Our unique network of experts and innovators share their knowledge and expertise through books, articles, and our online learning platform. O’Reilly’s online learning platform gives you on-demand access to live training courses, in-depth learning paths, interactive coding environments, and a vast collection of text and video from O’Reilly and 200+ other publishers. For more information, visit https://oreilly.com. Preface | ix

How to Contact Us Please address comments and questions concerning this book to the publisher: O’Reilly Media, Inc. 1005 Gravenstein Highway North Sebastopol, CA 95472 800-889-8969 (in the United States or Canada) 707-829-7019 (international or local) 707-829-0104 (fax) support@oreilly.com https://www.oreilly.com/about/contact.html We have a web page for this book, where we list errata, examples, and any additional information. You can access this page at https://oreil.ly/identity-native-infrastructure- access. For news and information about our books and courses, visit https://oreilly.com. Find us on LinkedIn: https://linkedin.com/company/oreilly-media Follow us on Twitter: https://twitter.com/oreillymedia Watch us on YouTube: https://youtube.com/oreillymedia Acknowledgments The authors would like to thank the team at O’Reilly Media for helping them through the process of writing this book. Our editor Jeff Bleiel was instrumental in getting this across the finish line. Also, thanks to Jennifer Pollock, Aleeya Rahman, and Carol Keller. Thank you to Jack Naglieri and Ken Westin for their contributions to Chapter 6. Thank you to Sasha Klizhentas for reviewing the access control material and to Prabath Siriwardena for additional technical review. x | Preface

CHAPTER 1 Introduction: The Pillars of Access Access to computing infrastructure becomes both more important and more difficult at scale. This book explores methods to make access easier, more scalable, and more secure. Computing infrastructure has a very broad meaning, but what we mean in this book is computing resources located in cloud environments, on-premises, or colocated data centers, and even Internet of Things (IoT) devices on public networks. The def‐ inition of computing resources includes hardware such as servers, networking, and storage, as well as infrastructure software such as databases, message queues, Kuber‐ netes clusters, monitoring dashboards, continuous integration/continuous delivery (CI/CD), and other DevOps tooling. Controlled access to this complex panoply has historically relied on the notion of a network perimeter and user credentials, the digital versions of what people use to control access to their homes: a door and a set of keys. A user credential, such as a password or a private key, is nothing more than a secret piece of information that unlocks a specific perimeter. All these secrets are just data—like any data, they can be lost, shared, copied, stolen, or even sold. Neither a physical key nor a digital key guarantees the identity of someone attempting access. Simply being in possession of the key allows access. When access management relies on secrets, it is giving access not to a client, but to the secret itself. This makes a stolen secret very powerful. Like most perimeter-based access control implementations, the front door lock on a house does nothing once an intruder gains access. Anyone with the single key to the house has access to all the valuables inside. Additional perimeter defenses inside the home have the same fundamental problem. Once an attacker is inside, everything is accessible. 1

Corporate networks that rely on secrets and perimeter defenses have the same weak‐ ness but worse. Perimeter-based security based on secrets is inadequate because: • The keys can be stolen, lost, or shared with someone legitimate and duplicated secretly. In other words, secrets are vulnerable to human error. • As infrastructure complexity increases, there can be too many entry points to protect, increasing operational overhead and leading to a growing thicket of vulnerabilities. • There can be many users with different access requirements for different resources, making it difficult to grant only the right access to every user. • An intruder who manages to gain access can easily pivot the attack to adjacent resources inside the perimeter, wreaking damage along the way. As a company grows, a secure access model based on a perimeter and secrets does not scale. All of the weaknesses above illustrate the same pattern: an attacker exploits human error, then pivots to get everywhere. Your computing infrastructure may consist of cloud accounts with API endpoints, virtual machines (VMs), databases, Kubernetes clusters, monitoring dashboards, and CI/CD tools. You may even have traditional data centers with the same resources running in them, and every single resource requires its own access. Configuring con‐ nectivity, authentication, authorization, and audit for every resource usually involves maintaining a myriad of configuration files, each with its own compliance require‐ ments and syntax. As the number of resources grows, the complexity of managing access to these components becomes unsustainable—and the cost of a configuration error becomes enormous. In this chapter, we begin the discussion of identity-native infrastructure access by showing how every breach or attack relies on the very characteristics that traditional security models encourage, reviewing the pillars of infrastructure access. We will lay out the ways that true identity-native infrastructure access solves all these challenges by eliminating the foundation that most infrastructure attacks rely upon: human error and the attacker’s ability to pivot. Most Attacks Are the Same Most infrastructure attacks follow the same human error + pivot pattern: 1. The attacker first gains a foothold into company-owned computing resources by exploiting human error. 2. The attacker then pivots to gain access to adjacent computing systems on the same network. 2 | Chapter 1: Introduction: The Pillars of Access

While human errors can be minimized with security training, rigorous recruiting, and other processes, they cannot be eliminated entirely. Humans will reliably be humans. Humans design vulnerable web applications, click malicious email attach‐ ments, leave their laptops on the subway, and commit API keys into public Git repositories. These errors and others leave a trail of exploitable vulnerabilities. Notice how every security-related human error revolves around some kind of secret. Passwords, private encryption keys, API keys, browser cookies, and session tokens are all hubs for human error. Every secret is a potential entry point for a malicious actor. Whenever a new secret is introduced into a computing environment, the probability of a breach increases. This probability may seem insignificant at first, and a successful breach may be unlikely in a small company; but as organizations scale, it becomes a question of when and not if. While a secret such as a password is intended to prove the identity expressed by the username, it does no such thing. Secrets-based access assumes that only the authorized person can possess the secret, but we know this is not true. A secret confers all the benefits of identity on an entity without any way to perform true authentication or authorization. Anybody with possession of a secret can pretend to be someone else. In that sense, the common term identity theft is misleading because what actually happens is a secret theft. A true identity cannot be shared, copied, or stolen. The probability of any single human making an error that leads to a compromised secret is relatively small, especially with a competent engineering team and a strong security culture. The introduction of robust processes and secret management solu‐ tions also reduce the probability of a secret leakage to an extremely low number, but they never bring it down to zero. In practice, the difference between a low number and zero is enormous when an organization operates at scale. To use memory corruption in a server as an analogy, the probability of a bit flip is extremely low. But as your infrastructure footprint expands and data volumes continue to grow, eventually there will be bit flips happening every minute. That’s why error correction code is mandatory at scale: it converts the probability of a bit flip from a very small number to zero. This happens for all kinds of low-probability events at scale. In a large data center, full-time employees are hired to replace hard drives all day, despite each drive having an expected lifespan of three years or more. Reliance on a secret for access is similar. The probability of a human leaking a secret by mistake may seem small. As infrastructure and teams grow, that small probability inevitably increases. As infrastructure becomes larger and more complex, the surface area of secrets becomes enormous, and the aggregated probability of a compromised secret becomes inevitable. That is why in a modern cloud native infrastructure the mere presence of a secret is considered a vulnerability. Most Attacks Are the Same | 3

It may be tempting to reduce the risk of a leaked secret by introducing more rigid processes. Draconian security procedures, while they provide a comforting illusion of safety, make engineers less productive and create incentives for bad behavior. Hard-to-use security measures lead people to use shorter passwords, build their own backdoors into infrastructure, keep secure sessions open for longer than needed, try to minimize the security team’s involvement in decision making, and take other shortcuts. Even the people who make the most earnest attempts to follow a difficult procedure will end up making a mistake eventually. It’s not the people who are the problem. It’s the secrets themselves. Secrets are just data; data is vulnerable to theft, loss, and copying. Companies such as Google and other so-called hyperscalers were among the first to face this reality, and have come up with a more scalable access architecture that hinges on two crucial patterns: • No secrets • Zero Trust This book covers these two patterns, explaining how they scale in real time with infrastructure without increasing the attack surface area or the probability of a breach. No secrets means no passwords, keys, or tokens. Eliminating secrets helps scale secure access because without secrets, there’s nothing to compromise, so human error is no longer exploitable. Instead of relying on secrets, access is based on identity itself. Zero Trust means that every user, device, application, and network address is inher‐ ently untrusted. There’s no perimeter because there’s no “inside” where entities are trusted. In a Zero Trust access model, every network connection is encrypted, every session must be authenticated, every client must be authorized, and the audit log is kept for every client action. With Zero Trust, every computing resource can safely run using a public IP address on an untrusted public network. Zero Trust greatly reduces the chance of pivot once an attacker gains control over a single machine and reduces the “blast radius” of an attack to just the one system initially compromised. Together, no secrets and Zero Trust help neutralize the human error + pivot pattern. With no secrets, human error doesn’t introduce vulnerabilities. With Zero Trust, there’s no “inside” to get to, so pivoting becomes meaningless. This gives us the freedom to think about access itself. 4 | Chapter 1: Introduction: The Pillars of Access

Access Access enables people, software, and hardware to work together securely. At its heart, access is a collection of privileges or permissions that allow a subject (a client) to perform certain actions on an object (a computing resource) for a period of time. Access control means mediating requests by subjects, often users, to access objects, using rights that determine the kind of access a specific subject is granted to a specific object. The intention is to control every access event within a system, protecting data and resources from unauthorized disclosure or modifications while ensuring access by legitimate users. Infrastructure access management is the ability to define and enforce how any client works with any resource. Managing access is the foundation of security in computer infrastructure, governing the use of all hardware and software, and how information is transferred, processed, and stored. Generally, managed access is remote because it involves communication among dif‐ ferent machines. In modern infrastructure at scale, it’s rare for someone to work only on a single, isolated machine. Remote access management is based on four pillars: Secure connectivity Secure communication over an untrusted network Authentication Proof of a client’s identity Authorization Specifying the actions a client can perform Audit A record of real-time and historical events These four components ensure that the right client has the right kind of access to protected resources, and that it’s possible for the right others to see what’s going on. The next sections provide a quick look at why each pillar is important. Subsequent chapters go into more detail about each one. Secure Connectivity Secure connectivity is the first pillar of access. A secure connection must be estab‐ lished before authentication can take place. To access a protected resource securely, an entity must be able to exchange messages without fear of interception. The legacy approach to connectivity relied on perimeter security, when encryption was needed only for messages leaving the network perimeter, also known as the local area network (LAN) or virtual private cloud (VPC). Anyone within the LAN or VPC was trusted. As infrastructure grows, the network becomes more complicated. Using Access | 5

virtual private networks (VPNs) and firewalls to stitch together perimeters to protect trusted areas becomes extremely challenging and leaves more and more holes. Even in the best case, perimeter-based security doesn’t work because it makes you vulnerable to attacker pivots. Interestingly, security is not the only argument against the perimeter. As more and more external services need connections into private networks, firewalls are basically just speed bumps. Effectively, the perimeter died a long time ago. That means there can be no such thing as a trusted network. This is what Zero Trust means. Encryption, authentication, authorization, and audit can’t rely on the network anymore and must shift from the network to the application layer. Requests can no longer be processed based on whether they’re on a trusted network. The network itself becomes untrusted, meaning that communication must be end-to-end encrypted at the session level. Thankfully, the technologies for this were invented a long time ago and are used for secure communications across the internet. All of us are already using them for online banking or shopping. We simply need to properly apply the same Zero Trust principles to our computing environments inside the LAN or VPC, not just on a perimeter. Authentication Authentication means proving identity. A person, computer, service, or other client requesting access to a protected resource must be able to prove it is who it says it is. When you see a login screen, that’s one type of authentication. Authentication must be kept separate from authorization, so that an entity’s permissions can be updated if its role changes. Authentication does not determine what an entity is allowed to do. Authentication only asserts identity. Verifying passwords is a popular authentication method, but it’s inadequate for prov‐ ing identity. After all, password-based authentication merely indicates possession of the secret itself and does not prove the bearer’s identity. Authentication must get to the heart of identity, which is a more difficult task. How do you prove the true identity of a person in the digital realm? One attempt at proving identity is multifactor authentication (MFA), which generally uses two or three different kinds of secrets to establish proof. This pattern is some‐ times called know + have + are, and often means a password (something you know), a one-time token generated by a separate device (something you have), and your biological traits (something you are). Unfortunately, common implementations of multifactor authentication simply convert the know + have pair of secrets into a session token or a browser cookie—just another secret, with all the problems that a secret entails. 6 | Chapter 1: Introduction: The Pillars of Access

Authentication is a hard problem, because it means translating the true identity of an entity—who a person is—into a digital form that doesn’t suffer from the same weaknesses as secrets. Authorization Once identity is established, authorization determines which actions a subject can perform—for example, read-only access versus full access. Thinking about authorization, it’s easy to see why secrets-based access is inadequate without a strong tie to an identity. Your house key gives you (or anyone who possesses it) the ability to enter your home, but it is your identity that gives you authorization to do so. You can grant authorization to others, allowing them to per‐ form specific actions. You might authorize someone to repair a leaky faucet or invite a friend to dinner. Hopefully, you’re granting these permissions based on identity rather than possession of a house key. Authorization is separate from authentication but relies on it. Without knowing who is requesting access to a resource, it’s impossible to decide whether to grant access. Authorization consists of policy definition and policy enforcement: deciding who has access to which resources and enforcing those decisions. The matrix of entities and permissions can be very large and complex and has often been simplified by creating access groups and categorizing resources into groups with defined permissions. This simplifies policy management but increases the blast radius of a breach. Someone with a stolen credential gains access to a broad group of resources based on the role to which the credential is assigned. Audit Audit shows which actions have been taken by every user or machine and which resources have been affected. The necessity of identifiable audit records—knowing who did what—is another reason why perimeter-based access does not scale. If you rely on a network boundary to authenticate clients, and the resources on an internal network are not protected, it means that all users become merged as a single “guest” (or worse: “admin”), making the audit logs useless. Once access shifts away from a perimeter-based approach to the resource and appli‐ cation level, generating more detailed and granular events, it becomes even more important to have both a real-time view and a historical record of access. Audit typically falls under the security terminology of manageability and traceability, with the important point being that you actually know and control what is going on in your environment. Identity-native infrastructure access management provides a great deal of control over individual access privileges, but the flip side of that is the responsibility to ensure Access | 7

that privileges are revoked when they are no longer needed. Regular audits can help minimize the risk of privileges being assigned incorrectly or lingering beyond when they’re needed. In other words, auditing is another hedge against human error. Having a real-time view and a historical record of access is a critical security capabil‐ ity. Shifting away from a perimeter-based approach to identity-native infrastructure access provides a great deal of control over access, because with audits each access can be tied back to an identity at an individual level. Security Versus Convenience Security and convenience are famously at odds with each other. When we approach our house after a grocery run, we are forced to slow down, put the bags on the porch, and reach for the keys. This is hardly convenient, especially when it rains! The inconvenience of security is even more evident in computing environments. Quite often, there are two groups of engineers involved in making decisions about remote access. On the one hand, we have software developers who need to fix bugs quickly, ship new features to customers, improve performance, and troubleshoot abnormalities—all under a tight timeline. On the other hand, there are security and compliance engineers who are primarily concerned with risk. These two groups have wildly different incentives. Software developers don’t want security in the way because it slows them down—and in many cases the way security is measured really has nothing to do with actual security. Security and compliance engineers are more concerned with reducing risk than with how fast things get done. As a result, there’s often tension between developers and security engineers, which sometimes takes the form of open conflict. A trade-off needs to be found. Organizations approach this in a variety of ways. Smaller technology startups err on the side of productivity, because their primary risk is not a security risk but a business risk. They may still be focusing on finding the product market fit, so the speed of product iteration is more important than compliance. As they mature, the balance starts to shift toward more robust security practices and compliance enforcement, trading off some of the product development velocity in the process. The industry shift to cloud computing has contributed to this dilemma. Engineers have gained more control over their infrastructure because the infrastructure itself is now provisioned with code. Oppressive security processes create incentives for engi‐ neers to implement their own shortcuts, which is easy with infrastructure-as-code provisioning. Often, management believes they have adopted solid security measures, while in reality their engineering team has devised its own ways of accessing cloud environments. This approach is called security theater. 8 | Chapter 1: Introduction: The Pillars of Access