800+ IT
News
als RSS Feed abonnieren📚 What is Zero Trust Automation?
💡 Newskategorie: IT Security Nachrichten
🔗 Quelle: twingate.com
Legacy network security solutions have become brittle, expensive, and increasingly vulnerable to attack. Zero Trust Network Access (ZTNA) promises a more consistent, responsive, and secure approach to access control. Despite these benefits, deploying and managing Zero Trust security architectures introduces new complexities. We will explain why secure perimeters are failing, how Zero Trust fits with modern network architectures, and how Zero Trust automation can speed your Zero Trust deployments.
Security and access in a complex world
Conventional secure perimeter approaches to access control are built upon an assumption that an outer layer of defenses is enough to protect a private network — and by extension, the network’s connected devices and resources. Secure perimeter technologies also assume that remote users’ credentials and devices, once authenticated, are always trustworthy.
Dynamic and decentralized IT ecosystem
As evidenced by constant reports of security breaches, the secure perimeter no longer works. Networks, resources, users, and devices are not confined within the business’ walls or under administrators’ direct control. Today’s networking ecosystem is decentralized and much more dynamic.
Distributed workforces - With today’s hybrid workforces many, if not most, employees are working from home. Blended workforces comprising employees, freelancers, and outside contractors are increasingly common. Managing this constantly-shifting user base requires access policies that apply to every combination of user and work location.
Device proliferation - Device management has become just as complicated. Bring-your-own-device (BYOD) policies have replaced managed devices and fractured administrators’ control over the device landscape. Access policies must support multiple form factors, manufacturers, and operating systems.
Decentralized networks - Thanks to cloud computing, many mission-critical systems have broken free of the secure perimeter. Any number of resources could be hosted on cloud platforms or outsourced to X-as-a-Service (XaaS) providers. As a result, the internet is as much a part of the “company network” as an on-premises LAN.
Failing secure perimeter architectures
Traditional secure perimeter frameworks cannot cope with today’s diverse, dynamic networking ecosystem for several reasons:
Over-reliance on trust - Once a VPN or other secure perimeter technology grants users access to a protected network, the users can see anything on that network. Hackers who compromise a user’s device or credentials get the same access and are free to move laterally, expanding their beachhead and escalating their credentials.
Fragmented infrastructure - Every cloud platform and XaaS provider has its own access control system. Administrators must somehow enforce consistent policies across a fragmented infrastructure without leaving gaps that hackers could exploit.
Administrative overhead - Traditional technologies embed access control into the physical network. Changes to access policies require changes to network hardware and vice versa. As a result, secure perimeters are brittle, unresponsive to new business requirements, and expensive to maintain.
Weaknesses in secure perimeters have become increasingly apparent. Solar Winds and other high-profile security breaches have forced IT leaders to face facts. Secure perimeters are not, and never will be, secure.
DevSecOps deployment challenges
Administrative overhead combined with brittle and fragmented infrastructures poses particular challenges for DevSecOps. Automation is essential to streamline the development, deployment, and management of IT infrastructures. However, integrating granular access control policies into these tools requires constant care and feeding. As a result, over-permissioned CI/CD tools and under-protected development and production environments expand the organization’s attack surface, putting sensitive data at risk.
Zero Trust security and access control
Zero Trust Network Access offers a better framework for providing secure access in today’s decentralized network ecosystem. Every federal agency has been told to develop a Zero Trust architecture strategy. In the private sector, businesses small and large see Zero Trust as the way to shrink their attack surface without hindering their business.
What is Zero Trust Network Access?
Zero Trust removes the secure perimeter’s inherent trust in networks, resources, devices, and users. Zero Trust security models are based on three core principles:
- Assume breach
- Verify explicitly
- Least privileged access
Assume breach reflects the reality of modern cybersecurity. Under persistent threat, any user, credential, device, resource, or network could be compromised at any time. ZTNA solutions deny all access requests by default until trust can be established.
Verify explicitly requires every user, no matter how high or low in the organization, to authenticate with every access request. Identity verification is not enough. The user’s network, their device’s security posture, and other context factors inform a ZTNA solution’s decision of whether to grant access.
Least privilege access policies provide granular control over which resources users may access and under which contexts. Zero Trust security policies limit users’ access to the specific resources they need for their work.
Zero Trust deployment guide
Initially, organizations struggled to justify the move to Zero Trust. Few had the resources to duplicate Google’s pioneering Zero Trust security model. Modern Zero Trust security practices using solutions such as Twingate’s make deploying Zero Trust much easier. However, this modern access framework is not without its challenges. IT infrastructure is split across network siloes. Configuring and deploying granular Zero Trust controls to provide both on-premises and cloud security is orders of magnitude more complex. Even for mid-sized organizations, automation is the only way to meet Zero Trust deployment objectives
Top Zero Trust deployment objectives
First, businesses need to know that a Zero Trust solution can control access to their cloud platforms in addition to on-premises resources. Unifying access control within a single system allows for simpler and more consistent policy enforcement across the business’ decentralized network architecture.
Additional deployment objectives
At the same time, businesses need ZTNA solutions that comply with good DevSecOps practices. Brittle network access controls often give automation tools too much access. As a result, systems with access to the most sensitive resources become security vulnerabilities. Zero Trust automation must be part of the systems development lifecycle, protecting the development process itself in addition to production resources.
Zero Trust Automation with Twingate
Twingate’s secure access solution was designed from the start to deliver enterprise-class Zero Trust Network Access with consumer-grade usability. Thanks to our software-based approach and automation capabilities, Twingate customers have deployed ZTNA globally in as little as fifteen minutes.
Unifying decentralized architectures
Twingate lets you deploy Zero Trust to any resource whether it runs on-premises or lives in the cloud. With a single docker command, you can deploy a Twingate Connector to AWS, Azure, and Google Cloud Compute to protect virtual machines, databases, and web apps. You can also use Twingate in the management of Kubernetes clusters or to securely access a service within an unexposed cluster.
Deployment automation
Although you can deploy Twingate’s components manually while learning how our solution works, you can use our solution with your existing Internet as Code (IAC) automation tools. Our Terraform and Pulumi providers, for example, let you script Connector deployments, definitions of Twingate-protected resources, and access provisioning for those resources. We also offer a GraphQL-based Admin API to automate your Twingate configuration as well as to provision Connectors and new tokens in code.
Least-privilege access in continuous integration
To test code that accesses protected resources, Continuous Integration (CI) tools such as Jenkins or Circle CI must have access to the same resources. In the past, that may have required constant maintenance of complex VPN configurations. Automatically deploying a Twingate Client into your CI tools lets them access the right protected resources while the code is being tested. Once the testing is complete, the permissions can be revoked programmatically.
Protecting source code, prod, and non-prod assets
If you use GitLab, GitHub, or other public repositories for version control, your source code could be at risk. Twingate lets you control access to these public repositories by requiring explicit verification and applying device posture tests to prevent unauthorized access.
Automation and orchestration
Twingate’s APIs also support your Zero Trust automation and orchestration workflows. Our Real-Time Analytics tool outputs connection logs from every Twingate Connector as single-line JSON objects. Security information and event management (SIEM) platforms such as Splunk or AWS CloudWatch can easily ingest these logs to automate the monitoring of your Zero Trust infrastructure.
Begin your Twingate Zero Trust journey
As legacy secure perimeter technologies continue to break under the pressures of today’s diverse, decentralized network ecosystem, Zero Trust Network Access promises to shrink attack surfaces dramatically while eliminating the brittle, expensive approaches of the past. Zero Trust deployments, however, introduce a new kind of complexity that could undermine DevSecOps productivity. Twingate’s Zero Trust solution integrates with your existing IAC strategies and CI/CD pipelines, letting you automate deployments and make development more secure.
Contact Twingate today to learn how easy Zero Trust automation can be.
...