Tag Archives: vpn

Looking Forward: Some Predictions for 2022

Post Syndicated from John Engates original https://blog.cloudflare.com/predictions-for-2022/

Looking Forward: Some Predictions for 2022

Looking Forward: Some Predictions for 2022

As the year comes to a close, I often reflect and make predictions about what’s to come in the next. I’ve written end-of-year predictions posts in the past, but this is my first one at Cloudflare. I joined as Field CTO in September and currently enjoy the benefit of a long history in the Internet industry with fresh eyes regarding Cloudflare. I’m excited to share a few of my thoughts as we head into the new year. Let’s go!

“Never make predictions, especially about the future.”
Casey Stengel

Adapting to a 5G world

Over the last few years, 5G networks have begun to roll out gradually worldwide. When carriers bombard us with holiday ads touting their new 5G networks, it can be hard to separate hype from reality. But 5G technology is real, and the promise for end-users is vastly more wireless bandwidth and lower network latency. Better network performance will make websites, business applications, video streaming, online games, and emerging technologies like AR/VR all perform better.

The trend of flexible work will also likely increase the adoption of 5G mobile and fixed wireless broadband. Device makers will ship countless new products with embedded 5G in the coming year. Remote workers will eagerly adopt new technology that improves Internet performance and reliability.

Companies will also invest heavily in 5G to deliver better experiences for their employees and customers. Developers will start re-architecting applications where more wireless “last mile”  bandwidth and lower wireless latency will have the most benefit. Similarly, network architects will seek solutions to improve the end-to-end performance of the entire network. In 2022, we’ll see massive investment and increased competition around 5G amongst network operators and cloud providers. Customers will gravitate to partners who can balance 5G network adoption with the most significant impact and the least cost and effort.

The talent is out there; it’s “just not evenly distributed.”

For various reasons, large numbers of workers changed jobs this year. In what has been called “the great resignation,” some claim there’s now a shortage of experienced tech workers. I’d argue that it’s more of a “great reshuffle” and consequently a race to attract and hire the best talent.

Work has changed profoundly due to the global pandemic over the last two years. People are now searching, applying, interviewing, onboarding, and working entirely remotely. Anyone looking to change jobs is likely evaluating potential employers on the working environment more than they did pre-2020.

Jobseekers are evaluating employers on different criteria than in the past. Does video conferencing work reliably? How streamlined is access to the software and tools I use every day? Can I work securely from different locations, or do the company’s security controls and VPN make it difficult to work flexibly?

Employers must make working flexibly easy and secure to attract the best talent. Even small amounts of digital friction are frustrating for workers and wasteful for employers. CIOs must take the lead and optimize the fully-digital, flexible work experience to compete for the very best talent. In 2022, I predict technology and tools will increasingly tip the balance in the talent war, and companies will look for every technological advantage to attract the talent they need.

Cloud Simply Increases

To eliminate some strain on employees, companies will search for ways to simplify their business processes and automate as much as possible. IT leaders will look for tasks they can outsource altogether. The best collaboration software and productivity tools tend to be delivered as-a-service.

It’s easy to predict more cloud adoption. But I don’t expect most companies to keep pace with how fast the cloud evolves. I was recently struck by how many services are now part of cloud provider portfolios. It isn’t easy for many companies to train employees and absorb these products fast enough. Another challenge is more cloud adoption means CEOs are often caught off guard by how much they are spending on the cloud. Lastly, there’s the risk that employee turnover means your cloud expertise sometimes walks out the door.

I predict companies will continue to adopt the cloud quickly, but IT leaders will expect cloud services to simplify instead of adding more complexity. Companies need the cloud to solve problems, not just provide the building blocks. IT leaders will ask for more bang for the buck and squeeze more value from their cloud partners to keep costs under control.

I also look forward to CIOs putting pressure on cloud providers to play nice with others and stop holding companies hostage. We believe egregious egress charges are a barrier to cloud adoption, and eliminating them would remove much of the cost and frustration associated with integrating services and leveraging multiple clouds.

“Everything should be made as simple as possible, but not simpler.”
Albert Einstein

Security is only getting more complicated. Companies must embrace zero trust

Throughout 2021, Cloudflare observed a steady rise in bot traffic and ever-larger DDoS attacks. As an industry, we’ve seen the trends of more phishing attempts and high-profile ransomware attacks. The recent emergence of the Log4j vulnerability has reminded us that security doesn’t take a holiday.

Given the current threat landscape, how do we protect our companies? Can we stop blaming users for clicking phishing emails? How do we isolate bad actors if they happen to find a new zero-day exploit like Log4j?

The only trend I see that brings me hope is zero trust. It’s been on the radar for a few years, and some companies have implemented point-products that are called zero trust. But zero trust isn’t a product or industry buzzword. Zero trust is an overarching security philosophy. In my opinion, far too few companies have embraced zero trust as such.

In 2022, CIOs and CISOs will increasingly evaluate (or reevaluate) technologies and practices in their security toolkit through the lens of zero trust. It should not matter how invested IT leaders are in existing security technology. Everything should be scrutinized, from managing networks and deploying firewalls to authenticating users and securing access to applications. If it doesn’t fit in the context of zero trust, IT managers should probably replace it.

The security-as-a-service model will tend to win for the same reasons I predicted more cloud. Namely, solving security problems as simply as possible with the fewest headcount required.

The corporate network (WAN) is dead. Long live the (Internet-based) corporate network

I can’t pinpoint the official time of death of the corporate WAN, but it was sometime between the advent of fiber-to-the-home and 5G wireless broadband. The corporate network has long suffered from high costs and inflexibility. SD-WAN was the prescription that extended the corporate network’s life, but work-from-home made the corporate network an anachronism.

Video conferencing and SaaS apps now run better at home than at the office for many of us. And the broader rollout of 5G will make things even better for mobile users. Your old VPN will soon disappear too. Shutting down the legacy VPN should be a badge of honor for the CISO. It’s a sign that the company has replaced the castle-and-moat perimeter firewall architecture and is embracing the zero trust security model.

In 2022 and beyond, the Internet will become the only network that matters for most users and companies. SaaS adoption and continued flexible work arrangements will lead companies to give up the idea of the traditional corporate network. IT leaders will likely cut budgets for existing WAN infrastructure to invest in more effective end-user productivity.

Matters of Privacy

Social media whistleblowers, end-to-end encryption, and mobile device privacy were on the minds of consumers in 2021. Consumers want to know whom they’re buying from and sharing data with, are they trustworthy, and what these companies do with the collected data?

Data privacy for businesses is critical to get right due to the scope of the privacy issues at hand. Historically, as some digital enterprises grew, there was a race to collect as much data as possible about their users and use it to generate revenue. The EU Global Data Protection Regulation (GDPR) has turned that around and forced companies to reevaluate their data collection practices. It has put power back into the hands of users and consumers.

GDPR is just one set of rules regulating the use of data about citizens. The US, EU, China, Russia, India, and Brazil have different views and regulations on privacy. Data privacy rules will not evolve the same everywhere, and it will be increasingly difficult for companies to navigate the patchwork of regulations around the globe.

Just as security is now a part of every software delivery stage, privacy needs to be considered throughout the development process. I predict that in 2022 and beyond, companies will architect applications with privacy laws in mind from the outset. About a year ago, we announced Cloudflare Data Localization Suite, which helps businesses take advantage of our global network’s performance and security benefits while making it easy to set rules to control where their data is handled automatically.

Another trend that spans the domains of privacy, security, and remote work is user preference for a single device for both personal and work-related activities. Carrying two or more devices is a hassle, but maintaining privacy and security on an unmanaged device presents challenges for IT. We will move away from the traditional tightly controlled, IT-managed device with time. Browser isolation and the evolution of zero trust security controls will get us closer to this holy grail of end-user device independence.


We have much to be thankful for, even with the challenges we’ve all faced in 2021. 2022 may well be as challenging as this year has been, but I predict it will be a great year, nonetheless. We’ll work hard, learn from our mistakes, and ultimately adapt to whatever life and work throw at us. At least that’s my plan for next year!

Zero Trust — Not a Buzzword

Post Syndicated from Fernando Serto original https://blog.cloudflare.com/zero-trust-not-a-buzzword/

Zero Trust — Not a Buzzword

Zero Trust — Not a Buzzword

Over the last few years, Zero Trust, a term coined by Forrester, has picked up a lot of steam. Zero Trust, at its core, is a network architecture and security framework focusing on not having a distinction between external and internal access environments, and never trusting users/roles.

In the Zero Trust model, the network only delivers applications and data to authenticated and authorised users and devices, and gives organisations visibility into what is being accessed and to apply controls based on behavioural analysis. It gained popularity as the media reported on several high profile breaches caused by misuse, abuse or exploitation of VPN systems, breaches into end-users’ devices with access to other systems within the network, or breaches through third parties — either by exploiting access or compromising software repositories in order to deploy malicious code. This would later be used to provide further access into internal systems, or to deploy malware and potentially ransomware into environments well within the network perimeter.

When we first started talking to CISOs about Zero Trust, it felt like it was just a buzzword, and CISOs were bombarded with messaging from different cybersecurity vendors offering them Zero Trust solutions. Recently, another term, SASE (Secure Access Services Edge), a framework released by Gartner, also came up and added even more confusion to the mix.

Then came COVID-19 in 2020, and with it the reality of lockdowns and remote work. And while some organizations took that as an opportunity to accelerate projects around modernising their access infrastructure, others, due to procurement processes, or earlier technology decisions, ended up having to take a more tactical approach, ramping up existing remote access infrastructure by adding more licenses or capacity without having an opportunity to rethink their approach, nor having an opportunity to take into account the impact of their employees’ experience while working remotely full time in the early days of the pandemic.

So we thought it might be a good time to check on organizations in Asia Pacific, and look at the following:

  • The pandemic’s impact on businesses
  • Current IT security approaches and challenges
  • Awareness, adoption and implementation of Zero Trust
  • Key drivers and challenges in adopting Zero Trust

In August 2021, we commissioned a research company called The Leading Edge to conduct a survey that touches on these topics. The survey was conducted across five countries — Australia, India, Japan, Malaysia, and Singapore, and 1,006 IT and cybersecurity decision-makers and influencers from companies with more than 500 employees participated.

For example, 54% of organisations said they saw an increase in security incidents in 2021, when compared to the previous year, with 83% of respondents who experienced security incidents saying they had to make significant changes to their IT security procedures as a result.

Zero Trust — Not a Buzzword
Increase in security incidents when compared to 2020. ▲▼ Significantly higher/lower than total sample

And while the overall APAC stats are already quite interesting, I thought it would be even more fascinating to look at the unique characteristics of each of the five countries, so let’s have a look:


Australian organisations reported the highest impact of COVID-19 when it comes to their IT security approach, with 87% of the 203 respondents surveyed saying the pandemic had a moderate to significant impact on their IT security posture. The two biggest cities in Australia (Sydney and Melbourne) were in lockdown for over 100 days, each in the second half of 2021 alone. With the extensive lockdowns, it’s not a surprise that 48% of respondents reported challenges with maximising remote workers’ productivity without exposing them or their devices to new risks.

With 94% of organisations in Australia having reported they will be implementing a combination of return to office and work from home, building an effective and uniform security approach can be quite challenging. If you combine that with the fact that 62% saw an increase in security incidents over the last year, we can safely assume IT and cybersecurity decision-makers and influencers in Australia have been working on improving their security posture over the last year, even though 40% of respondents indicated they struggled to secure the right level of funding for such projects.

Australia seems to be well advanced on the journey into implementing Zero Trust when compared to other four countries included in the report, with 45% of the organisations that have adopted Zero Trust starting their Zero Trust journey over the last one to four years. Australian organisations have always been known for fast cloud adoption, and even in the early 2010s Australians were already consuming IaaS quite heavily.


When compared to the other countries in the report, India has a very challenging environment when it comes to working from home, with Internet connectivity being inconsistent, even though there’s been significant improvement in internet speeds in the country, and problems like power outages regularly occurring in certain areas outside of city centres. Surprisingly, the biggest challenge reported by Indian organisations was that they could benefit from newer security functionality, which goes to show that legacy security approaches are still widely present in India. Likewise, 37% of the respondents reported that their access technologies are too complex, which supports the previous point that newer security functionality would be beneficial to the same organisations.

When asked about their concerns around the shift in how their users will access applications, one of the biggest concerns raised by 59% of the respondents was around applications being protected by VPN or IP address controls alone. This shows Zero Trust would fit really well with their IT strategy moving forward, as controls can now be applied to users and their devices.

Another interesting point to make, and where Zero Trust can be leveraged, is 65% of respondents saying internal IT and security staff shortage and cuts is a huge challenge. Most security technologies out there would require special skills to build, maintain and operate, and this is where simplifying access with the right Zero Trust approach could really help improve the productivity of those teams.


When we look at the results of the survey across all five countries, it’s fairly obvious that Japan didn’t seem to have quite the same challenges as the other countries when the pandemic started. Businesses continued to operate normally for most of 2020 and 2021, which would explain why the impact wasn’t in line with the other countries. Having said that, 51% of the respondents surveyed in Japan still reported they saw a moderate to significant impact in their IT security approach, which is still significant, even though lower than the other countries.

Japanese organisations also reported an increase in the number of security incidents, which supports the fact that even though the impact of the pandemic wasn’t as severe as in other countries, 45% of the respondents still reported an increase in security incidents, and 63% still had to make changes to their IT security procedures as a direct result of incidents.


Malaysia rated second highest (at 80%) in our report on the impact the pandemic has had on organisations’ IT security approach, and rated highest on both employees using their home networks and using personal devices for work, at 94% and 92% respectively. From a security perspective, that poses a significant impact to an organization’s security posture and increases the attack surface for an organisation substantially.

From a risk perspective, Malaysian organisations rated lack of management over employees’ devices pretty highly, with 65% of them expressing concerns over it. Other areas worth calling out were applications and data being exposed to the public Internet, and lack of visibility into staff activity inside applications.

With 57% of the respondents calling out an increase in security incidents when compared to the previous year, 89% of the respondents said they had to make significant changes to their IT security procedures due to either security incidents or attack attempts against their environments.


In Singapore, 79% of IT and cybersecurity decision-makers and influencers reported that the pandemic has impacted their IT security approach, and two in five organisations said they could benefit from more modern security functionality as a direct result of the impact caused by the pandemic. 52% of the organisations also reported an increase in security incidents compared to 2020, with almost half having seen an increase in phishing attempts.

Singaporean organisations were also not immune to a significant increase in IT security spend as a direct result of the pandemic, with 62% of them having reported more investment in security. Some of the challenges these organisations were facing were related to applications being directly exposed to the public Internet, limited oversight on third party access and applications being protected by username and password only.

While Singapore is known for high speed home Internet, it was quite a surprise for me to see that 40% of organisations surveyed reported issues with latency or slow connectivity into applications via VPN. This goes to show that the problem of concentrating traffic into a single location can impact application performance even across relatively small geographies, and even if bandwidth is not necessarily a problem, like what happens in Singapore.

The work in IT security never stops

While there were distinct differences in each country around IT security posture and Zero Trust adoption, across Asia Pacific, the similarities are what stand out the most:

  • Cyberattacks continue to rise
  • Flexible work is here to stay
  • Skilled in-house IT security workers are a scarce resource
  • Need to educate stakeholders around Zero Trust

These challenges are not easy to tackle, add to these the required focus on improving employee experience, reducing operational complexities, better visibility into 3rd party activity, and tighter controls due to the increase in security incidents, and you’ve got a heck of a huge responsibility for IT.

And this is where Cloudflare comes in. Not only have we been helping our employees work security throughout the pandemic, we have also been helping organisations all over the globe streamline their IT security operations when it comes to users accessing applications through Cloudflare Access, or securing their activity on the Internet through our Secure Web Gateway services, which even includes controls around SaaS applications and browser isolation, all with the best possible user experience.

So come talk to us!

Authenticate AWS Client VPN users with AWS Single Sign-On

Post Syndicated from Sylvia Qi original https://aws.amazon.com/blogs/security/authenticate-aws-client-vpn-users-with-aws-single-sign-on/

AWS Client VPN is a managed client-based VPN service that enables users to use an OpenVPN-based client to securely access their resources in Amazon Web Services (AWS) and in their on-premises network from any location. In this blog post, we show you how you can integrate Client VPN with your existing AWS Single Sign-On via a custom SAML 2.0 application to authenticate and authorize your Client VPN connections and traffic.

Maintaining a separate set of credentials to authenticate users and authorize access for each resource is not only tedious, it’s not scalable. A common way to solve this challenge is to use a central identity store such as AWS SSO, which functions as your identity provider (IdP). You can then use Security Assertion Markup Language 2.0 (SAML 2.0) to integrate AWS SSO with each of your resources or applications, also known as service providers (SPs). The IdP authenticates users and passes their identity and security information to the SP via SAML. With SAML, you can enable a single sign-on experience for your users across many SAML-enabled applications and services. Users authenticate with the IdP once using a single set of credentials, and then have access to multiple applications and services without additional sign-ins.

Client VPN supports identity federation with SAML 2.0 for Client VPN endpoints. Deploying custom SAML applications can present some challenges, specifically around the mapping of attributes between what the SP expects to receive and what the IdP can provide. We’ve taken the guesswork out of the process and show you the exact mappings needed for the Client VPN to AWS SSO integration. The integration lets you use AWS SSO groups to not only grant access to create a Client VPN connection, but also to allow access to specific network ranges based upon group membership. We walk you through setting up all of the components required to implement the authentication workflow described in Figure 1. This consists of creating the custom SAML applications and tying them into AWS Identity and Access Management (IAM), creating and configuring the Client VPN endpoint, creating a Client VPN connection with an AWS SSO user, and testing your connectivity.

Figure 1: Authentication workflow

Figure 1: Authentication workflow

The steps illustrated in Figure 1 are:

  1. The user opens the AWS-provided VPN client on their device and initiates a connection to the Client VPN endpoint.
  2. The Client VPN endpoint sends an IdP URL and authentication request back to the client, based on the information that was provided in the IAM SAML provider.
  3. The AWS provided VPN client opens a new browser window on the user’s device. The browser makes a request to the IdP and displays a sign-in page. This is the same sign-in experience as the AWS SSO user portal, as the IdP URL points to a custom SAML application created within AWS SSO.
  4. The user enters their credentials on the sign-in page, and the IdP sends a signed SAML assertion back to the client in the form of an HTTP POST to the AWS provided VPN client.
  5. The SAML assertion is passed from the AWS provided VPN client to the Client VPN endpoint.
  6. The endpoint validates the assertion and either allows or denies access to the user.


Here are the requirements to complete the VPN and SSO setup:

  • AWS SSO is configured to use the internal AWS SSO identity store. Refer to the AWS Single Sign-On Getting Started guide for help configuring AWS SSO. AWS SSO can exist in a different AWS account than the account where you deploy Client VPN endpoints. The steps outlined in this blog post are specific to the internal AWS SSO identity store, however they could be adapted to support other identity stores that support SAML 2.0.
  • Two AWS SSO users and two AWS SSO groups for testing. Each user should be a member of only one of the SSO groups. The purpose of this configuration is to demonstrate how access can be allowed or denied based upon group membership.
  • An Amazon Virtual Private Cloud (Amazon VPC) with an Amazon Elastic Compute Cloud (Amazon EC2) instance for connectivity testing.
  • An x.509 certificate imported into AWS Certificate Manager (ACM). You can generate a self-signed certificate for this walkthrough, however you should review the prerequisites for importing certificates into ACM. This certificate will be used for encrypted communication between the client VPN software and the client VPN endpoint.
  • Administrative access to your AWS environment, or at least sufficient access to create AWS SSO applications, ACM certificates, EC2 Instances, and Client VPN endpoints.
  • A client device running Windows or macOS with the latest version of Client VPN software installed. You can download it from the AWS Client VPN download.

Solution walkthrough

For this solution, you’ll complete the following steps:

  1. Establish trust with your IdP
  2. Create and configure Client VPN SAML applications in AWS SSO.
  3. Integrate the Client VPN SAML applications with IAM.
  4. Create and configure the Client VPN endpoint.
  5. Test the solution.
  6. Cleanup the test environment.

Establish trust with your IdP

In this walkthrough, Client VPN is the SAML SP and AWS SSO is the SAML IdP. One of the key steps to deploying this solution is to establish trust between the SP and IdP. This one-time configuration is done by creating custom SAML applications within AWS SSO and exporting application-specific metadata information from the applications. This metadata is then uploaded—in the form of IAM IdPs—into your AWS account where the Client VPN endpoint is created. IAM IdPs let you manage your user identities in a centralized identity store, such as AWS SSO, and grant those user identities permissions to AWS resources within your account. For organizations with multiple AWS accounts, the use of IAM IdPs resolves the management, scalability, and security issues associated with creating IAM users directly within each account.

Create and configure the Client VPN SAML applications in AWS SSO

Create two custom SAML 2.0 applications in AWS SSO. One will be the IdP for the Client VPN software, the other will be a self-service portal that allows users to download their Client VPN software and client configuration file.

To create the VPN client SAML application:

  1. In the AWS SSO console, select Applications from the left pane and select Add a new application.
  2. Select Add a custom SAML 2.0 application to use as the IdP for the Client VPN software.
    Figure 2: Add a SAML application

    Figure 2: Add a SAML application

  3. In the Details section, set Display name to VPN Client.
  4. In the Application Metadata section, select If you don’t have a metadata file, you can manually type your metadata values and enter the following values:
    • Application ACS URL:
    • Application SAML audience: urn:amazon:webservices:clientvpn
  5. Accept the default values for all other fields.
  6. Choose Save Changes.
  7. Select the Attribute mappings tab and configure the mappings as shown in the table and Figure 3 below.

    Note: For production environments, you should grant access to these applications via an AWS SSO group instead of individual users as shown in this walkthrough.

    User attribute in the application Maps to this string value or user attribute in AWS SSO Format
    Subject ${user:email} emailAddress
    Name ${user:email} unspecified
    FirstName ${user:givenName} unspecified
    LastName ${user:familyName} unspecified
    memberOf ${user:groups} unspecified
    Figure 3: VPN client attribute mappings

    Figure 3: VPN client attribute mappings

  8. On the Assign users tab, add your two test user accounts.
  9. On the application configuration page, choose the download link for AWS SSO SAML metadata. Save the file to use in a later step.

To create the VPN client self-service SAML application

  1. In the AWS SSO console, select Applications from the left pane and select Add a new application.
  2. Select Add a custom SAML 2.0 application to use as the application that will serve as the IdP for the Client VPN software.
    Figure 4: Add a SAML application

    Figure 4: Add a SAML application

  3. In the Details section, set Display name to VPN Client Self Service.
  4. In the Application Metadata section, select If you don’t have a metadata file, you can manually type your metadata values and enter the following values:
    • Application ACS URL: https://self-service.clientvpn.amazonaws.com/api/auth/sso/saml
    • Application SAML audience: urn:amazon:webservices:clientvpn
  5. Accept the default values for all other fields.
  6. Choose Save Changes.
  7. Choose the Attribute mappings tab and configure the mappings as shown in the following table and in Figure 5.

    Note: For production environments you should grant access to these applications via an AWS SSO group instead of individual users as shown in this walkthrough. For the purposes of this walkthrough, you grant individual users access to the SAML applications but grant network access via group membership. This is done to allow easier demonstration of the ability to grant or deny network specific access via groups when testing the solution.

    User attribute in the application Maps to this string value or user attribute in AWS SSO Format
    Subject ${user:email} emailAddress
    Name ${user:email} unspecified
    FirstName ${user:givenName} unspecified
    LastName ${user:familyName} unspecified
    memberOf ${user:groups} unspecified
    Figure 5: VPN Client self-service attribute mappings

    Figure 5: VPN Client self-service attribute mappings

  8. On the Assign users tab, add your two test user accounts.
  9. On the application’s Configuration page, choose the download link for AWS SSO SAML metadata. Save the file to use in a later step.

Integrate the Client VPN SAML applications with IAM

Client VPN requires a unique IdP definition in IAM. You must set up the IdP in the same AWS account where the Client VPN endpoint will be created.

To create the IAM IdP:

  1. In the IAM console, select Identity providers and Add provider. Name the provider aws-client-vpn and upload the metadata document that you downloaded from the VPN Client SAML application.
  2. Add a second provider, name the provider aws-client-vpn-self-service and upload the metadata document that you downloaded from the VPN Client Self Service SAML application.

Create and configure the Client VPN endpoint

All Client VPN sessions end at the Client VPN endpoint. You configure the Client VPN endpoint to manage and control all Client VPN sessions. In the following steps, you create a Client VPN endpoint and configure it to use the newly added IAM IdPs. You then associate the endpoint with a VPC and configure authorization rules to allow traffic into the VPC, then set up the Client VPN self-service portal.

To create the Client VPN endpoint

  1. Open the AWS VPC console and select Client VPN Endpoints and then select Create Client VPN endpoint.
  2. Enter a Name Tag and Description for the endpoint.
  3. Enter for the Client IPv4 CIDR. This is the IP range that will be allocated to your VPN clients. It shouldn’t overlap the CIDR of your AWS VPCs or of the network that your client device is connected to and must be at least a /22 bitmask. You can adjust this value as needed for your specific network requirements. The Client IPv4 CIDR value can only be set during endpoint creation.

    Note: For production environments you should review the Client VPN documentation for scaling considerations before you create the endpoint.

  4. In the Server certificate ARN drop down menu, select the ACM certificate that you created for your VPN clients.
  5. Set the Authentication Options to Use user-based authentication with Federated authentication. Select the aws-client-vpn IAM IdP for the SAML provider ARN, and select the aws-client-vpn-self-service IAM IdP as the Self-service SAML provider ARN.
    Figure 6: Authentication settings

    Figure 6: Authentication settings

  6. For this walkthrough, set Connection Logging to No. Connection logging is a feature of Client VPN that enables you to capture connection logs for your Client VPN endpoint. Those logs are published to an Amazon CloudWatch Logs log group in your account. For production environments or for troubleshooting purposes, you can enable connection logging while or after you create the endpoint.
  7. Select the VPC ID to associate with the endpoint. This should be the VPC with an EC2 instance deployed that can be used to test connectivity. You can select an existing security group, or create a new one for the VPN endpoint. The only requirement for this walkthrough is that it has outbound rules that allow access to your test EC2 instance. For additional flexibility, you can create and apply multiple security groups that use different rulesets to the endpoint to provide fine-grained control of which resources can be accessed within the VPC.
  8. Select Enable self-service portal and—if desired—select Enable split-tunnel. Split tunneling is designed to ensure that only client traffic destined for the IP ranges configured on the Client VPN endpoint is routed to your VPC. By default, all traffic, including internet bound traffic, is routed through your VPC.
  9. Choose Create Client VPN endpoint.

To configure the Client VPN endpoint

  1. On the Client VPN endpoint Associations tab, select Associate. Select the same VPC that you chose when you set up the endpoint and select a subnet to associate. This creates an elastic network interface (ENI) in the selected subnet that will be the ingress point from VPN clients into your AWS VPC. For production environments, you should select at least two subnets based upon your redundancy requirements.
  2. Authorizing VPN ingress traffic from your users can be done either globally for all users or via group membership. When granting access via an AWS SSO group, you must use the group ID of the AWS SSO group, not the friendly name of the group. After selecting a group in the AWS SSO management console, you can find group ID in the Details section. You can also obtain the group ID by using AWS Command Line Interface (AWS CLI) to issue the following command, replacing the <AWSRegion>, <Identity Store ID>, and <AWS SSO Group Display Name> variables with your information. This command should be issued within the same AWS account where AWS SSO is configured. The identity store ID can be found in the AWS SSO console under Settings.
    aws identitystore list-groups --region <AWSRegion> --identity-store-id <Identity Store ID> --filter AttributePath=DisplayName,AttributeValue=<AWS SSO Group Display Name>

  3. Create an ingress authorization rule by selecting Authorize Ingress on the Authorization tab. Configure the destination network to enable as, set Grant access to: Allow access to users in a specific access group and enter the access group ID that you discovered in the previous step. This should be the group that contains one of your test user accounts. For production environments, you should follow the principle of least privilege and narrow the destination network range to only what is required. Ingress authorization rules can be used to restrict network access to specific network ranges based upon IdP group membership. You can use a client connection handler to enforce additional security policies on Client VPN connections. Refer to the Client VPN documentation for additional details.
    Figure 7: Add authorization rule

    Figure 7: Add authorization rule

  4. From the Client VPN Endpoint Summary tab, copy the Self-service portal URL to use in the next step.

To set up the Client VPN self-service portal

  1. Open the Client VPN self-service SAML application in the AWS SSO management console to edit the configuration.
  2. In the Application start URL textbox, paste the Client VPN endpoint self-service portal URL that you copied in the previous section. This ties the Client VPN self-service SAML application to the self-service portal URL for the specific Client VPN endpoint that you created, allowing users to download their AWS VPN Client configuration file.
    Figure 8: Client VPN self-service portal

    Figure 8: Client VPN self-service portal

Test the solution

During the testing phase, you download the VPN client configuration file and configure the VPN client application. You then create a Client VPN connection and validate that you have access to your target VPC. You also test the Client VPN connection with multiple user accounts in order to confirm that the ingress authorization rules are functioning as expected.

To test the Client VPN solution:

  1. Open an internet browser and sign in to your AWS SSO user portal as a user who has access to the VPN Client SAML applications and is a member of the AWS SSO group defined in the VPN endpoint ingress authorization rule. You should see two new SAML applications. Select the VPN client self-service application.
  2. In the VPN Client Self Service portal, you can download the AWS VPN Client software if you haven’t already done so. Select Download client configuration and save the file on your local device. Close the browser window that you used to sign in to the AWS SSO user portal.
  3. Open the AWS VPN Client application and configure a new profile, selecting the client configuration file that you downloaded in the previous step. Once your client profile has been created, select Connect.
    Figure 9: VPN Client ready to connect

    Figure 9: VPN Client ready to connect

  4. A new browser window should open automatically to an AWS SSO sign-in page. Enter the credentials of your test user who is a member of the AWS SSO group defined in your ingress authorization rule.
  5. Upon a successful connection through the VPN client, you can make a management connection (RDP, SSH, HTTP, or other) to one of the EC2 instances within your VPC. Connect to the private IPv4 address of your EC2 instance (rfc1918)—you should not attempt to connect to your EC2 instance through an EIP. You might need to adjust the security group rules on your EC2 instance to allow traffic from the subnets that you selected when you created the VPN endpoint associations.
  6. Once you have a successful connection to your test EC2 instance and you know that your Client VPN connectivity is working, you should also validate that access is denied for users who aren’t a member of the group specified in your ingress authorization rule.
    1. Disconnect from your Client VPN connection and close all browser windows.
    2. Depending upon your internet browser and its configuration, you might need to delete any cookies associated with your AWS SSO user portal in order to sign in as a different AWS SSO user.
    3. Initiate a new Client VPN connection and sign in as the test user account that is not a member of the AWS SSO group specified in the ingress authorization rule.
    4. You should be able to successfully establish the Client VPN connection, but not to access your test EC2 instance. This validates that the ingress authorization rule isn’t allowing Client VPN traffic from users who aren’t a member of the AWS SSO group to enter your VPC.


If you have any issues completing the walkthrough and testing, here are some things that you can check:

  • In the AWS VPC management console, review the Connections tab to verify that you see a connection from your test user account and that it’s active.
  • Confirm that your test user account is in the group that was defined in your ingress authorization rule.
  • Confirm that the access group ID specified in the ingress authorization rule is for the AWS SSO group that your test user is a member of.
  • Confirm that the AWS SSO group still exists and hasn’t been deleted. You might encounter an error message similar to the one shown in Figure 10 if you attempt a Client VPN connection but the AWS SSO group no longer exists.
    Figure 10: Error message

    Figure 10: Error message

  • If you receive a credential error when attempting to sign in to the AWS SSO browser window that’s launched by the VPN Client application, you might have an issue with the ACM certificate that you’re using. There can be authentication related issues if the root CA certificates aren’t correct or if any part of the certificate chain is missing.
  • Validate your EC2 instance security group rules and VPC route table configuration. From a routing perspective, your test EC2 instance must be accessible from the subnet that you selected when you created the Client VPN endpoint association.
  • If you want to see the SAML assertion that’s being sent to the AWS VPN client application. Sign in to the AWS SSO user portal, and hold down the Shift key while selecting the VPN client SAML application. A new browser tab will open with the SAML assertion visible. The SAML assertion contains the access group IDs of all groups that your test user is a member of. You can use this information to validate that the correct group memberships and group IDs are defined in your ingress authorization rules.
  • Make sure that TCP port 35001 is available on your client device. It shouldn’t be used by any other process or blocked by a firewall. Port 35001 only needs to be open on your localhost interface. The SAML assertion is sent to localhost on port 35001 as an HTTP POST from the browser window opened by the AWS VPN client application after a successful sign-in.

Clean up the test environment

To avoid charges for the use of AWS EC2, Client VPN, SSO, or ACM services, remove any components that were created as part of this walkthrough. Components that can be deleted if applicable are:

  1. The Client VPN endpoint. You must first remove all associations that were created for the endpoint.
  2. The EC2 instance and VPC.
  3. The test IdPs from IAM.
  4. The VPN client custom SAML applications from AWS SSO.
  5. AWS SSO users and groups.
  6. The ACM certificate.


In this blog post, we’ve shown how you can integrate Client VPN and AWS SSO to provide a familiar and seamless VPN connection experience to your users. By adding the Client VPN self-service portal, you can reduce the effort needed to deploy the solution by allowing users to perform their own VPN client application installation and configuration. We demonstrated the creation of IdPs using AWS SSO custom applications and then showed you how to configure a Client VPN endpoint to use SAML-based federated authentication and associate it with the IdPs. Client VPN users can then use their centralized credentials to connect to the Client VPN endpoint and access specific network ranges based upon their group membership or further refined through a client connection handler.

If you have feedback about this post, submit comments in the Comments section below.

Want more AWS Security how-to content, news, and feature announcements? Follow us on Twitter.


Drew Marumoto

Drew is a DevOps Consultant with Aws Professional Service. A long time system administrator with a passion for automation and orchestration, he enjoys solving difficult problems for customers and helping them achieve their business goals.


Sylvia Qi

Sylvia is a DevOps Consultant focusing on architecting and automating DevOps processes, helping customers through their DevOps transformation journey, and achieving their goals. In her spare time, she enjoyes biking, swimming, painting, and photograhy.

How to restrict IAM roles to access AWS resources from specific geolocations using AWS Client VPN

Post Syndicated from Artem Lovan original https://aws.amazon.com/blogs/security/how-to-restrict-iam-roles-to-access-aws-resources-from-specific-geolocations-using-aws-client-vpn/

You can improve your organization’s security posture by enforcing access to Amazon Web Services (AWS) resources based on IP address and geolocation. For example, users in your organization might bring their own devices, which might require additional security authorization checks and posture assessment in order to comply with corporate security requirements. Enforcing access to AWS resources based on geolocation can help you to automate compliance with corporate security requirements by auditing the connection establishment requests. In this blog post, we walk you through the steps to allow AWS Identity and Access Management (IAM) roles to access AWS resources only from specific geographic locations.

Solution overview

AWS Client VPN is a managed client-based VPN service that enables you to securely access your AWS resources and your on-premises network resources. With Client VPN, you can access your resources from any location using an OpenVPN-based VPN client. A client VPN session terminates at the Client VPN endpoint, which is provisioned in your Amazon Virtual Private Cloud (Amazon VPC) and therefore enables a secure connection to resources running inside your VPC network.

This solution uses Client VPN to implement geolocation authentication rules. When a client VPN connection is established, authentication is implemented at the first point of entry into the AWS Cloud. It’s used to determine if clients are allowed to connect to the Client VPN endpoint. You configure an AWS Lambda function as the client connect handler for your Client VPN endpoint. You can use the handler to run custom logic that authorizes a new connection. When a user initiates a new client VPN connection, the custom logic is the point at which you can determine the geolocation of this user. In order to enforce geolocation authorization rules, you need:

  • AWS WAF to determine the user’s geolocation based on their IP address.
  • A Network address translation (NAT) gateway to be used as the public origin IP address for all requests to your AWS resources.
  • An IAM policy that is attached to the IAM role and validated by AWS when the request origin IP address matches the IP address of the NAT gateway.

One of the key features of AWS WAF is the ability to allow or block web requests based on country of origin. When the client connection handler Lambda function is invoked by your Client VPN endpoint, the Client VPN service invokes the Lambda function on your behalf. The Lambda function receives the device, user, and connection attributes. The user’s public IP address is one of the device attributes that are used to identify the user’s geolocation by using the AWS WAF geolocation feature. Only connections that are authorized by the Lambda function are allowed to connect to the Client VPN endpoint.

Note: The accuracy of the IP address to country lookup database varies by region. Based on recent tests, the overall accuracy for the IP address to country mapping is 99.8 percent. We recommend that you work with regulatory compliance experts to decide if your solution meets your compliance needs.

A NAT gateway allows resources in a private subnet to connect to the internet or other AWS services, but prevents a host on the internet from connecting to those resources. You must also specify an Elastic IP address to associate with the NAT gateway when you create it. Since an Elastic IP address is static, any request originating from a private subnet will be seen with a public IP address that you can trust because it will be the elastic IP address of your NAT gateway.

AWS Identity and Access Management (IAM) is a web service for securely controlling access to AWS services. You manage access in AWS by creating policies and attaching them to IAM identities (users, groups of users, or roles) or AWS resources. A policy is an object in AWS that, when associated with an identity or resource, defines their permissions. In an IAM policy, you can define the global condition key aws:SourceIp to restrict API calls to your AWS resources from specific IP addresses.

Note: Throughout this post, the user is authenticating with a SAML identity provider (IdP) and assumes an IAM role.

Figure 1 illustrates the authentication process when a user tries to establish a new Client VPN connection session.

Figure 1: Enforce connection to Client VPN from specific geolocations

Figure 1: Enforce connection to Client VPN from specific geolocations

Let’s look at how the process illustrated in Figure 1 works.

  1. The user device initiates a new client VPN connection session.
  2. The Client VPN service redirects the user to authenticate against an IdP.
  3. After user authentication succeeds, the client connects to the Client VPN endpoint.
  4. The Client VPN endpoint invokes the Lambda function synchronously. The function is invoked after device and user authentication, and before the authorization rules are evaluated.
  5. The Lambda function extracts the public-ip device attribute from the input and makes an HTTPS request to the Amazon API Gateway endpoint, passing the user’s public IP address in the X-Forwarded-For header.Because you’re using AWS WAF to protect API Gateway, and have geographic match conditions configured, a response with the status code 200 is returned only if the user’s public IP address originates from an allowed country of origin. Additionally, AWS WAF has another rule configured that blocks all requests to API Gateway if the request doesn’t originate from one of the NAT gateway IP addresses. Because Lambda is deployed in a VPC, it has a NAT gateway IP address, and therefore the request isn’t blocked by AWS WAF. To learn more about running a Lambda function in a VPC, see Configuring a Lambda function to access resources in a VPC.The following code example showcases Lambda code that performs the described step.

    Note: Optionally, you can implement additional controls by creating specific authorization rules. Authorization rules act as firewall rules that grant access to networks. You should have an authorization rule for each network for which you want to grant access. To learn more, see Authorization rules.

  6. The Lambda function returns the authorization request response to Client VPN.
  7. When the Lambda function—shown following—returns an allow response, Client VPN establishes the VPN session.
import os
import http.client

cloud_front_url = os.getenv("ENDPOINT_DNS")
endpoint = os.getenv("ENDPOINT")
success_status_codes = [200]

def build_response(allow, status):
    return {
        "allow": allow,
        "error-msg-on-failed-posture-compliance": "Error establishing connection. Please contact your administrator.",
        "posture-compliance-statuses": [status],
        "schema-version": "v1"

def handler(event, context):
    ip = event['public-ip']

    conn = http.client.HTTPSConnection(cloud_front_url)
    conn.request("GET", f'/{endpoint}', headers={'X-Forwarded-For': ip})
    r1 = conn.getresponse()

    status_code = r1.status

    if status_code in success_status_codes:
        print("User's IP is based from an allowed country. Allowing the connection to VPN.")
        return build_response(True, 'compliant')

    print("User's IP is NOT based from an allowed country. Blocking the connection to VPN.")
    return build_response(False, 'quarantined')

After the client VPN session is established successfully, the request from the user device flows through the NAT gateway. The originating source IP address is recognized, because it is the Elastic IP address associated with the NAT gateway. An IAM policy is defined that denies any request to your AWS resources that doesn’t originate from the NAT gateway Elastic IP address. By attaching this IAM policy to users, you can control which AWS resources they can access.

Figure 2 illustrates the process of a user trying to access an Amazon Simple Storage Service (Amazon S3) bucket.

Figure 2: Enforce access to AWS resources from specific IPs

Figure 2: Enforce access to AWS resources from specific IPs

Let’s look at how the process illustrated in Figure 2 works.

  1. A user signs in to the AWS Management Console by authenticating against the IdP and assumes an IAM role.
  2. Using the IAM role, the user makes a request to list Amazon S3 buckets. The IAM policy of the user is evaluated to form an allow or deny decision.
  3. If the request is allowed, an API request is made to Amazon S3.

The aws:SourceIp condition key is used in a policy to deny requests from principals if the origin IP address isn’t the NAT gateway IP address. However, this policy also denies access if an AWS service makes calls on a principal’s behalf. For example, when you use AWS CloudFormation to provision a stack, it provisions resources by using its own IP address, not the IP address of the originating request. In this case, you use aws:SourceIp with the aws:ViaAWSService key to ensure that the source IP address restriction applies only to requests made directly by a principal.

IAM deny policy

The IAM policy doesn’t allow any actions. What the policy does is deny any action on any resource if the source IP address doesn’t match any of the IP addresses in the condition. Use this policy in combination with other policies that allow specific actions.


Make sure that you have the following in place before you deploy the solution:

Implementation and deployment details

In this section, you create a CloudFormation stack that creates AWS resources for this solution. To start the deployment process, select the following Launch Stack button.

Select the Launch Stack button to launch the template

You also can download the CloudFormation template if you want to modify the code before the deployment.

The template in Figure 3 takes several parameters. Let’s go over the key parameters.

Figure 3: CloudFormation stack parameters

Figure 3: CloudFormation stack parameters

The key parameters are:

  • AuthenticationOption: Information about the authentication method to be used to authenticate clients. You can choose either AWS Managed Microsoft AD or IAM SAML identity provider for authentication.
  • AuthenticationOptionResourceIdentifier: The ID of the AWS Managed Microsoft AD directory to use for Active Directory authentication, or the Amazon Resource Number (ARN) of the SAML provider for federated authentication.
  • ServerCertificateArn: The ARN of the server certificate. The server certificate must be provisioned in ACM.
  • CountryCodes: A string of comma-separated country codes. For example: US,GB,DE. The country codes must be alpha-2 country ISO codes of the ISO 3166 international standard.
  • LambdaProvisionedConcurrency: Provisioned concurrency for the client connection handler. We recommend that you configure provisioned concurrency for the Lambda function to enable it to scale without fluctuations in latency.

All other input fields have default values that you can either accept or override. Once you provide the parameter input values and reach the final screen, choose Create stack to deploy the CloudFormation stack.

This template creates several resources in your AWS account, as follows:

  • A VPC and associated resources, such as InternetGateway, Subnets, ElasticIP, NatGateway, RouteTables, and SecurityGroup.
  • A Client VPN endpoint, which provides connectivity to your VPC.
  • A Lambda function, which is invoked by the Client VPN endpoint to determine the country origin of the user’s IP address.
  • An API Gateway for the Lambda function to make an HTTPS request.
  • AWS WAF in front of API Gateway, which only allows requests to go through to API Gateway if the user’s IP address is based in one of the allowed countries.
  • A deny policy with a NAT gateway IP addresses condition. Attaching this policy to a role or user enforces that the user can’t access your AWS resources unless they are connected to your client VPN.

Note: CloudFormation stack deployment can take up to 20 minutes to provision all AWS resources.

After creating the stack, there are two outputs in the Outputs section, as shown in Figure 4.

Figure 4: CloudFormation stack outputs

Figure 4: CloudFormation stack outputs

  • ClientVPNConsoleURL: The URL where you can download the client VPN configuration file.
  • IAMRoleClientVpnDenyIfNotNatIP: The IAM policy to be attached to an IAM role or IAM user to enforce access control.

Attach the IAMRoleClientVpnDenyIfNotNatIP policy to a role

This policy is used to enforce access to your AWS resources based on geolocation. Attach this policy to the role that you are using for testing the solution. You can use the steps in Adding IAM identity permissions to do so.

Configure the AWS client VPN desktop application

When you open the URL that you see in ClientVPNConsoleURL, you see the newly provisioned Client VPN endpoint. Select Download Client Configuration to download the configuration file.

Figure 5: Client VPN endpoint

Figure 5: Client VPN endpoint

Confirm the download request by selecting Download.

Figure 6: Client VPN Endpoint - Download Client Configuration

Figure 6: Client VPN Endpoint – Download Client Configuration

To connect to the Client VPN endpoint, follow the steps in Connect to the VPN. After a successful connection is established, you should see the message Connected. in your AWS Client VPN desktop application.

Figure 7: AWS Client VPN desktop application - established VPN connection

Figure 7: AWS Client VPN desktop application – established VPN connection


If you can’t establish a Client VPN connection, here are some things to try:

  • Confirm that the Client VPN connection has successfully established. It should be in the Connected state. To troubleshoot connection issues, you can follow this guide.
  • If the connection isn’t establishing, make sure that your machine has TCP port 35001 available. This is the port used for receiving the SAML assertion.
  • Validate that the user you’re using for testing is a member of the correct SAML group on your IdP.
  • Confirm that the IdP is sending the right details in the SAML assertion. You can use browser plugins, such as SAML-tracer, to inspect the information received in the SAML assertion.

Test the solution

Now that you’re connected to Client VPN, open the console, sign in to your AWS account, and navigate to the Amazon S3 page. Since you’re connected to the VPN, your origin IP address is one of the NAT gateway IPs, and the request is allowed. You can see your S3 bucket, if any exist.

Figure 8: Amazon S3 service console view - user connected to AWS Client VPN

Figure 8: Amazon S3 service console view – user connected to AWS Client VPN

Now that you’ve verified that you can access your AWS resources, go back to the Client VPN desktop application and disconnect your VPN connection. Once the VPN connection is disconnected, go back to the Amazon S3 page and reload it. This time you should see an error message that you don’t have permission to list buckets, as shown in Figure 9.

Figure 9: Amazon S3 service console view - user is disconnected from AWS Client VPN

Figure 9: Amazon S3 service console view – user is disconnected from AWS Client VPN

Access has been denied because your origin public IP address is no longer one of the NAT gateway IP addresses. As mentioned earlier, since the policy denies any action on any resource without an established VPN connection to the Client VPN endpoint, access to all your AWS resources is denied.

Scale the solution in AWS Organizations

With AWS Organizations, you can centrally manage and govern your environment as you grow and scale your AWS resources. You can use Organizations to apply policies that give your teams the freedom to build with the resources they need, while staying within the boundaries you set. By organizing accounts into organizational units (OUs), which are groups of accounts that serve an application or service, you can apply service control policies (SCPs) to create targeted governance boundaries for your OUs. To learn more about Organizations, see AWS Organizations terminology and concepts.

SCPs help you to ensure that your accounts stay within your organization’s access control guidelines across all your accounts within OUs. In particular, these are the key benefits of using SCPs in your AWS Organizations:

  • You don’t have to create an IAM policy with each new account, but instead create one SCP and apply it to one or more OUs as needed.
  • You don’t have to apply the IAM policy to every IAM user or role, existing or new.
  • This solution can be deployed in a separate account, such as a shared infrastructure account. This helps to decouple infrastructure tooling from business application accounts.

The following figure, Figure 10, illustrates the solution in an Organizations environment.

Figure 10: Use SCPs to enforce policy across many AWS accounts

Figure 10: Use SCPs to enforce policy across many AWS accounts

The Client VPN account is the account the solution is deployed into. This account can also be used for other networking related services. The SCP is created in the Organizations root account and attached to one or more OUs. This allows you to centrally control access to your AWS resources.

Let’s review the new condition that’s added to the IAM policy:

"ArnNotLikeIfExists": {
    "aws:PrincipalARN": [

The aws:PrincipalARN condition key allows your AWS services to communicate to other AWS services even though those won’t have a NAT IP address as the source IP address. For instance, when a Lambda function needs to read a file from your S3 bucket.

Note: Appending policies to existing resources might cause an unintended disruption to your application. Consider testing your policies in a test environment or to non-critical resources before applying them to production resources. You can do that by attaching the SCP to a specific OU or to an individual AWS account.


After you’ve tested the solution, you can clean up all the created AWS resources by deleting the CloudFormation stack.


In this post, we showed you how you can restrict IAM users to access AWS resources from specific geographic locations. You used Client VPN to allow users to establish a client VPN connection from a desktop. You used an AWS client connection handler (as a Lambda function), and API Gateway with AWS WAF to identify the user’s geolocation. NAT gateway IPs served as trusted source IPs, and an IAM policy protects access to your AWS resources. Lastly, you learned how to scale this solution to many AWS accounts with Organizations.

If you have feedback about this post, submit comments in the Comments section below.

Want more AWS Security how-to content, news, and feature announcements? Follow us on Twitter.


Artem Lovan

Artem is a Senior Solutions Architect based in New York. He helps customers architect and optimize applications on AWS. He has been involved in IT at many levels, including infrastructure, networking, security, DevOps, and software development.


Faiyaz Desai

Faiyaz leads a solutions architecture team supporting cloud-native customers in New York. His team guides customers in their modernization journeys through business and technology strategies, architectural best practices, and customer innovation. Faiyaz’s focus areas include unified communication, customer experience, network design, and mobile endpoint security.

Backdoor in Zyxel Firewalls and Gateways

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2021/01/backdoor-in-zyxel-firewalls-and-gateways.html

This is bad:

More than 100,000 Zyxel firewalls, VPN gateways, and access point controllers contain a hardcoded admin-level backdoor account that can grant attackers root access to devices via either the SSH interface or the web administration panel.


Installing patches removes the backdoor account, which, according to Eye Control researchers, uses the “zyfwp” username and the “PrOw!aN_fXp” password.

“The plaintext password was visible in one of the binaries on the system,” the Dutch researchers said in a report published before the Christmas 2020 holiday.

Configuring AWS VPN for UK public sector use

Post Syndicated from Charlie Llewellyn original https://aws.amazon.com/blogs/security/configuring-aws-vpn-for-uk-public-sector-use/

In this post, we explain the United Kingdom (UK) National Cyber Security Centre (NCSC)’s guidance on VPN profiles configuration, and how the configuration parameters for the AWS Virtual Private Network (AWS VPN) align with the NCSC guidance. At the end of the post, there are links to code to deploy the AWS VPN in line with those parameters.

Many public sector organizations in the UK need to connect their existing on-premises facilities, data centers, or offices to the Amazon Web Services (AWS) cloud so they can take advantage of the broad set of services AWS provides to help them deliver against their mission.

This can be achieved using the AWS VPN service. However some customers find it difficult to know the exact configuration parameters that they should choose when establishing the VPN connection in-line with guidance for the UK public sector.

AWS VPN services enable organizations to establish secure connections between their on-premises networks, remote offices, and client devices and the AWS global network. AWS VPN comprises two services: AWS Site-to-Site VPN and AWS Client VPN. Together, they deliver a highly available, fully managed, elastic cloud VPN solution to protect your network traffic.

For the purposes of this post, we focus on the Site-to-Site VPN configuration, not Client VPN because the NCSC guidance we’re discussing is specifically related to site-to-site VPNs. This post covers two areas:

  • An overview of the current guidance for VPN configurations for the public sector.
  • Recommendations on how to configure AWS VPN to meet or exceed the current guidance.

VPN guidance for UK public sector organizations

The starting point for security guidance for the UK public sector is often the NCSC. The role of the NCSC includes:

  • Protecting government systems and information.
  • Planning for and responding to cyber incidents.
  • Working with providers of critical national infrastructure to improve the protection and computer security of such infrastructure against cyber-borne threats.

Specifically, for guidance on the configuration of VPNs for the UK public sector to support data at OFFICIAL, the NCSC has created detailed guidance on the technical configurations to support two different profiles: PRIME and Foundation. These two profiles provide different technical implementations to support different equipment and are both suitable for use with OFFCICIAL data. Beyond these technical differences, NCSC also documents that Foundation is expected to provide suitable protection for OFFICIAL information until at least December 31, 2023, while PRIME has no review date specified at the time of writing.

This guidance is available in Using IPsec to protect data.

Let’s start by debunking a few myths.

Myth 1: I have to adhere exactly to the NCSC technical configuration or I cannot use a VPN for OFFICIAL data

It’s a common misconception that a public sector organization must adhere exactly to the configuration of either PRIME or Foundation in order to use a VPN for OFFICIAL data, even if other configuration options available—such as a longer key length—offer a higher security baseline.

Note that the NCSC isn’t mandating the use of the configuration in their guidance. They’re offering a configuration that provides a useful baseline, but you must assess your use of the NCSC guidance in context of the risks. To help with these risk-based decisions, the NCSC has developed a series of guidance documents to help organizations make risk-based decisions. A common consideration that might require deviating from the guidance would be supporting interoperability with legacy systems where the suggested algorithms aren’t supported. In this case, a risk-based decision should be made—including accounting for other factors such as cost.

It’s also worth noting that the NCSC creates guidance designed to be useful to as many organizations as possible. The NCSC balances adopting the latest possible configurations with backwards compatibility and vendor support. For example, the NCSC suggests AES-128 where—in theory—AES-256 could also be a good choice. Organizations need to be aware that if they choose to adopt devices that support only AES-256 and later need to connect in devices capable of only AES-128, there could be significant investment to replace the legacy devices with ones that support AES-256. However, AWS provides both AES-128 and AES-256, so if the remote device supports it, AWS would recommend opting for AES-256.

The NCSC also tries to develop advice that has some longevity. For example, the guidance suggesting use of AES-128 was created in 2012 with a view to providing solid guidance over a number of years. This means customers can choose different configuration parameters that offer increased levels of security if both sides of the VPN can support it.

It’s possible for a customer to choose options that might lower the security of the connection, provided that risks are identified and appropriately managed by the customers assurance team. This might be needed to support interoperability between existing systems where the cost of an upgrade outweighs the risk.

Myth 2: Foundation has been deprecated and I must use PRIME

Another common misconception is that Foundation has been deprecated in favor of PRIME. This is not the case. The NCSC has stated that Foundation is expected to provide suitable protection for OFFICIAL information until at least December 31, 2023. The security provided by both solutions provides commensurate security for accessing data classified as OFFICIAL. One of the main differences between PRIME and Foundation is the choice of signature algorithm: RSA or ECDSA. This difference can be helpful in enabling an organization to choose which profile to adopt. For example, if the organization already has a private key infrastructure (PKI), then the decision regarding which signature algorithm to use is based on what existing systems support.

Myth 3: I can’t use Foundation for accessing OFFICIAL SENSITIVE data

A final point that often causes confusion is the classifying of data at OFFICIAL SENSITIVE because it isn’t a classification, but a handling caveat. The data would be classified as OFFICIAL and marked as OFFICIAL SENSITIVE, meaning that systems handling the data need risk-appropriate security measures. A system that can handle OFFICIAL data might be appropriate to handle sensitive information. Hence Foundation could be suitable for accessing OFFICIAL SENSITIVE data, depending on the risks identified.

Deep-dive into the technical specifications

Now that you know a little more about how the guidance should be viewed, let’s look more closely at the technical configurations for each VPN profile.

The following table shows the configuration parameters suggested by the NCSC VPN guidance discussed previously.

Technical detail Foundation PRIME
IKEv* – Encryption IKEv1 – AES with 128-bit keys in CBC mode (RFC3602) IKEv2 – AES-128 in GCM-128 (and optionally CBC)
IKEv2 – Pseudo-random function HMAC-SHA256 HMAC-SHA256
IKEv2 – Diffie-Hellman group Group 14 (2048-bit MODP group) (RFC3526) 256 bit random ECP (RFC5903) Group 19
IKEv2 – Authentication X.509 certificates with RSA signatures (2048 bits) and SHA-256 (RFC4945 and RFC4055) X.509 certificates with ECDSA-256 with SHA256 on P-256 curve
ESP – Encryption AES with 128-bit keys in CBC mode (RFC3602)
SHA-256 (RFC4868)
AES-128 in GCM-128
SHA-256 (RFC4868)

Recommended AWS VPN configuration for public sector

Bearing in mind these policies, and remembering that the configuration is only guidance, you must make a risk-based decision. AWS recommends the following configuration as a starting point for the configuration of the AWS VPN.

Technical detail AWS configuration Adherence
IKEv* – Encryption IKEv2 – AES-256-GCM Suitable for Foundation and PRIME
IKEv2 – Pseudo-random function HMAC-SHA256 Meets Foundation and PRIME
IKEv2 – Diffie-Hellman group Group 19 Suitable for Foundation and matches PRIME
IKEv2 – Authentication RSA 2048 SHA2-512 Suitable for Foundation
ESP – Encryption AES-256-GCM Suitable for PRIME and Foundation

In the table above, we use the term suitable for where the protocol doesn’t match the guidance exactly but the AWS configuration options provide equivalent or stronger security—for example, by using a longer key length.

With the configuration defined above, the AWS VPN service is suitable for use under the Foundation profile in all areas. It can also be made suitable for PRIME in all areas apart from IKEv2 encryption. The use of RSA or ECDSA is the main difference between the AWS VPN and PRIME configurations. This makes the current AWS VPN solution closer to Foundation than PRIME.

When considering which options are available to you, the starting point should be the capabilities of your current—and possible future—VPN devices. Based on its capabilities, you can use the NCSC guidance and preceding tables to choose the protocols that match or are suitable for the NCSC guidance.


To review:

  • The NCSC provides guidance for the VPN configuration, not a mandate.
  • An organization is free to decide not to use the guidance, but should consider risks when they make that decision.
  • The AWS VPN meets or is suitable for the configuration options for Foundation.

After reviewing the details contained in this blog, UK public sector organizations should have the confidence to use the AWS VPN service with systems running at OFFICIAL.

If you’re interested in deploying the AWS VPN configuration described in this post, you can download instructions and AWS CloudFormation templates to configure the AWS VPN service. The AWS VPN configuration can be deployed to either connect directly to a single Amazon Virtual Private Cloud (Amazon VPC) using a virtual private gateway, or to an AWS Transit Gateway to enable its use by multiple VPCs.

If you’re interested in configuring your AWS VPN tunnel options manually, you can follow Modifying Site-to-Site VPN tunnel options.

If you have feedback about this post, submit comments in the Comments section below.

Want more AWS Security how-to content, news, and feature announcements? Follow us on Twitter.


Charlie Llewellyn

Charlie is a Solutions Architect working in the Public Sector team with Amazon Web Services. He specializes in data analytics and enjoys helping customers use data to make better decisions. In his spare time he avidly enjoys mountain biking and cooking.


Muhammad Khas

Muhammad Khas is a Solutions Architect working in the Public Sector team at Amazon Web Services. He enjoys supporting customers in using artificial intelligence and machine learning to enhance their decision making. Outside of work, Muhammad enjoys swimming, and horse riding.

NSA on Securing VPNs

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2020/07/nsa_on_securing.html

The NSA’s Central Security Service — that’s the part that’s supposed to work on defense — has released two documents (a full and an abridged version) on securing virtual private networks. Some of it is basic, but it contains good information.

Maintaining a secure VPN tunnel can be complex and requires regular maintenance. To maintain a secure VPN, network administrators should perform the following tasks on a regular basis:

  • Reduce the VPN gateway attack surface
  • Verify that cryptographic algorithms are Committee on National Security Systems Policy (CNSSP) 15-compliant
  • Avoid using default VPN settings
  • Remove unused or non-compliant cryptography suites
  • Apply vendor-provided updates (i.e. patches) for VPN gateways and clients

Тихата безкръвна революция: Интернет отвръща на цифровото проследяване с децентрализиран VPN

Post Syndicated from Екип на Биволъ original https://bivol.bg/tachyon-vpn.html

неделя 10 май 2020

В магазините на Google и AppStore се появи ново приложение – Tachyon VPN. Малко по-рано бе пусната алфа-версия на този безплатен VPN за MacOS, а скоро ще излезе версията за Windows.

„Ех пък и намерили информационен повод за статия в пресата! Че и с „революция“ в заглавието!“ – ще се дръпне читателят и ще се окаже, че не е прав. Защото Tachyon не е поредният сервиз за безопасна и анонимна работа в мрежата, а първият VPN в историята, работещ в блокчейн и готов за използване от редовия потребител.

В Tachyon няма централизирани сървъри, които някой може да блокира, тъй като обменът на информация се осъществява в партньорска мрежа между участниците. Всеки от участниците пък изпълнява ролята на сървър. Целият трафик в Tachyon е кодиран с криптиране от край до край, а да го проследиш е невъзможно,

защото по-рано шифрованите данни се пренасят през интернет с помощта на симулирани обикновени протоколи /HTTP и TLS/, без по никакъв начин да се отличават от окръжаващия поток данни. И, в крайна сметка:

Tachyon VPN е невъзможно нито да се закрие, нито да се забрани, нито да се накаже

Защото този сервиз няма началство, протоколът е отворен, а управлението на блокчейна и мрежата се осъществява чрез традиционната за криптоиндустрията структура – DAO, децентрализирана автономна организация, в която всички решения се приемат с общо равнопоставено гласуване на анонимните участници в мрежата.


Главното, според мен, достойнство на Tachyon VPN е в пределната простота на използването: инсталирате приложението от магазина на Google или Apple, отваряте го – и на екрана виждате единствен бутон: Включи/Изключи. Кликвате и след секунда цялата ваша комуникация е скрита за страничните очи.

При това знаете, че никой не може да принуди вашия доставчик на услугите VPN да се регистрира някъде и да споделя някаква информация. Не, защото вашият доставчик е такъв принципен и упорит, а защото няма кой да бъде задължен за това – няма щаб-квартира, няма ръководител, юридическо лице също липсва. Остава, едва ли не, всеки редови потребител на мрежата Tachyon да бъде заплашван. Но и това е безполезно, защото самите потребители не знаят нищо, освен собствения си трафик.

Колкото повече наблюдавам развитието на събитията в света, толкова по-силно се поддавам на възхищението – до какво ли така подредено и съразмерно върви постъпателното движение към новата глобална парадигма на съществуването на човечеството от старата! Новата парадигма се нарича E Unibus Pluram /От едно – много/. Заимствах тази фраза от есето на американския писател Дейвид Фостър Уолъс, който, на свой ред, е обърнал крилатата фраза на Цицерон „E Pluribus Unum“ /От многото – едно/, украсяващо герба на САЩ.

Прехода към новата парадигма ние наблюдаваме навсякъде:

– Вместо централизирания интернет вече има Web 3.0, в който информацията се съхранява разпределена в шифрован вид в компютрите на редовите потребители на световната Мрежа /Blockstack, Filecoin, Graphite Docs и др./.

– Вместо йерархичната система DNS, основана на разрешаващи сървъри и контролирана от шепа американски компании, а същевременно и вместо националните реплики на тази уязвима структура са включени сервизи с имена на домейни, реализирани в децентрализирани блокчейни /Ethereum Naming Service, Handshake, Unstoppable Domains и др./

– Вместо тоталитарните социални мрежи са създадени и пуснати алтернативни децентрализирани блокчейн-площадки; Facebook е реализиран в Minds, вместо Reddit и Twitter има Hive, Golos, Steem и Commun, вместо Instagram има All.me, вместо LinkedIn има Indorse.

– Вместо фиатни пари с безгранична инфлационна емисия, контролируема от централните банки на държавите, съществуват множество криптовалути, предоставящи широк спектър функции – от спестовни /Bitcoin/ до пълна анонимност (Monero, Zcash, Beam и др./.

– Вместо банковото оценъчно-разрешително кредитиране са създадени десетки сервизи DeFI /децентрализирано финансиране/, където всеки потребител може сам да вземе или да предостави кредит, без да иска от никого разрешение, доколкото изпълнението на задължените страни безпристрастно се контролира не от юридически структури, а от математически проверени смарт-договори / Maker, Compund, Aave, dYdX, bZx, Sablier, Dharma, Fulcrum и др./.

В тази картина липсваше последното звено – този същият предходен вид, в дарвинския смисъл на думата, без който е невъзможно раждането на новото качество. Такова звено дойде като Tachyon VPN, обединил инфраструктурата на традиционния интернет с новите технологии на пълната децентрализация в човешките отношения.

През двата месеца тестване на Tachyon VPN броят на потребителите му надскочи 150 000 души. Успехът е абсолютно феноменален за блокчейн-продуктите, които с огромен труд достигат до масовия потребител.

Сдържаността на всеки човек е лесна за разбиране. Първо, хората се опариха от безкраен поток от измами, стартирани под прикритието на ICO през 2016-2018 г. лъвският дял на тези афери се падна на Русия, страните от бившия ОНД, Източна Европа и Азия, което се обяснява с бедността на населението. Когато няма спестявания, няма и особено какво да се губи, поради това нашите хора са готови да заравят монетки в първото им попаднало Поле на Чудесата, обещаващо бързо забогатяване.

Второ, правителствените медии в цял свят упорито формират негативно отношение към криптотехнологиите, като създават в обществото измамни конотации на криптовалутата с тероризма, педофилията, търговията с наркотици и международните криминални групировки. Всичко това, разбира се, е безсмислица, доколкото делът на криптовалутата в нелегалния търговски оборот не превишава 1%. Но ефектът на доверието към правителствените медии действа безотказно – попитайте 10 души на улицата за биткойна и 9 от тях ще отговорят, че това е афера или престъпление.

Трето, блокчейн-технологиите са сложни за масово възприемане. Всъщност, сложно е всичко, което ни заобикаля – от автомобила до интернета. Но и автомобилът, и интернет отдавна достигнаха пределното ниво на адаптация за обикновения човек – за да постигнеш желания резултат е достатъчно да натиснеш бутона.

До този момент блокчейн-технологиите се намираха на същото равнище, на което беше и интернет в началото на 90-те години. Спомням си, че първото си включване в световната Мрежа настройвах в Windows for Workgroups 3.11 повече от денонощие – първо четях в списания за компютри за информационните форуми /BBS/, на които може да се намери Winsock API от странични разработчици Chameleon и Trumpet (Winsock – това е специален фреймуърк за работа с протокол TCP/IP, който беше вграден в ОС първо само в Windows 95/, после с часове настройвах дузина параметри, после поотделно конфигурирах приложения за работа с поща, конференция на новини и сървъри FTP.
Това беше ужасно и единици ползваха интернет. Също толкова ужасно изглеждаха и нещата с блокчейн-продуктите, които само специалисти можеха да настроят.

Днес ние се оказваме свидетели на последната, решаващата стъпка – превода на сложните блокчейн-технологии на езика на „един клик“. За да получим или дадем пари на кредит при гаранцията на безпристрастния смарт-договор, е достатъчно да изтеглим приложението на мобилния си телефон и да кликнем на бутона на дисплея. За да се възползваме от VPN за блокчейн, също не се налага нищо да настройваме – клик! И всичко работи.

Предвиждам и възражения – алтернативите на социалните мрежи, реализирани в блокчейн, съществуват относително неотдавна, но не се налага да говорим за никаква конкуренция с Facebook и ВКонтакте. Само вижте високотехнологичната социална мрежа №1 в блокчейн minds.com – чиста проба Зомбиленд, където са се приютили без работа два и половина потребители. При това всичко в minds.com е интуитивно, всичко е привично и познато, а единствената разлика с Facebook е в това, че липсват Цукърбърг или друг началник, които биха могли да ви баннат за това, че сте казали нещо неправилно /според неговото, цукърбърговското разбиране за правилно и неправилно/.

На практика алтернативните социални мрежи са пусти, но вината за това изобщо не е на блокчейн-технологиите, а самата идея на социалната мрежа, която се вдъхновява само от масовото стълпотворение – колкото повече народ се струпа на площадката, толкова повече площадката е привлекателна.

Социално активната публика непременно ще премине към децентрализираните мрежи, но ще направи това последно, само след като алтернативните технологии основателно стеснят традиционните сервизи на интернета по силата на своите обективни преимущества.

Съвсем по друг начин стоят нещата с VPN. Тук внедряването на блокчейн-технологиите се очаква вече отдавна и с голямо нетърпение.

Интересът на обществото към защитата на комуникациите в интернет се проявява навсякъде, дори и да е неравномерно разпределен в геополитическо отношение. Например, в страните на западната цивилизация VPN ползват от 4% /в Австралия/ до 6% /в Германия/ от потребителите на интернет.

Не така е в страните от Третия свят – в Индия и турция – 18%, в Китай – 20%, в Тайланд и русия – около 24%.
Само помислете: една четвърт от редовите потребители на мрежата, които компютърните гикове (ентусиазирани до обсесия от технологиите б.ред.) са свикнали да считат за леймъри (неосведомени, невежи б.ред.), се справят забележително с такава технология като VPN.

Главната заслуга в популяризирането на VPN в нашето отечество, без съмнение, принадлежи на Роскомнадзор. Последната вълна на народния интерес към този преди неведом сервиз се случи, след като Роскомнадзор успешно се пребори с Telegram. В името на справедливостта трябва да се каже, че масовата популярност на VPN бе осигурена все пак не от Месинджър, а от пиратския видеоконтент и торент-тракерите, които, впрочем, Роскомнадзор също блокира. Поради това лаврите за популяризирането на технологията очевидно остават за този орган.

С други думи, популярността на Tachyon беше предопределена от потребността на пазара на самия сервиз за анонимизиране на трафика. Не по-малко важна роля изигра и блокчейн-технологията, която прави невъзможен натиска върху компанията, предоставяща услугите на VPN.

При сънародниците ми е налице забележителен прецедент – през март миналата година Роскомнадзор разпрати писма до десетина крупни VPN-провайдери с изискването да се включат в държавната информационна система. Девет от тях очаквано се отказаха /всички, освен Kaspersky Secure Connection, което също беше очаквано/, прибраха своите сървъри от територията на Руската федерация и спокойно продължиха предоставянето на услугите си.

Рискувам все пак да предположа, че въпросната реакция се случи само заради това, че мнението на Роскомнадзор не интересува никого извън пределите на Русия, още повече – никого не плаши.

Представете си, че идентично изискване би повдигнал американският събрат на Роскомнадзор за борбата за чистота на политическите нрави – Агенцията за национална сигурност на САЩ. Дали изобщо някой счита, че отговорът на NordVPN, Hide My Ass!, Hola VPN, Openvpn, VyprVPN, ExpressVPN, TorGuard, IPVanish и VPN Unlimited би бил подобен на този от случая с руското ведомство?

На всички, които си пазят геополитическите илюзии, предлагам да си спомнят за съдбата на продуктите на Facebook /Libra/ и Telegram /TON/, свързани с криптотехнологиите – и двата бяха пречупени като дървеница още преди се появят на бял свят.

Прелестта и надеждността на VPN, базиран на блокчейн-технологиите, се състои в това, че там няма кого да пречупваш и тормозиш – нито физически /със завземане на сървърното оборудване/, нито юридически /с обявяване извън закона на територията на националните юрисдикции/.

Преди всичко, аз бих искал да се поздравим всички ние не просто с настъпването на цифровата революция, а с революцията от нов тип. Новината й се крие в морално-етичното великолепие – за пръв път в историята се случва безкръвна революция! Не, защото хорските нрави са станали по-малко кръвожадни, а защото изчезват обектите и субектите на натиска. Воистину – E Unibus Pluram!

Автор: Сергей Голубицкий, Новая газета 

Превод: Екип на Биволъ
***Руското издание „Новая газета“ е част от Международния консорциум на разследващите журналисти /OCCRP/, където е и сайтът Биволъ.

Migrating from VPN to Access

Post Syndicated from Achiel van der Mandele original https://blog.cloudflare.com/migrating-from-vpn-to-access/

Migrating from VPN to Access

Migrating from VPN to Access

With so many people at Cloudflare now working remotely, it’s worth stepping back and looking at the systems we use to get work done and how we protect them. Over the years we’ve migrated from a traditional “put it behind the VPN!” company to a modern zero-trust architecture. Cloudflare hasn’t completed its journey yet, but we’re pretty darn close. Our general strategy: protect every internal app we can with Access (our zero-trust access proxy), and simultaneously beef up our VPN’s security with Spectrum (a product allowing the proxying of arbitrary TCP and UDP traffic, protecting it from DDoS).

Before Access, we had many services behind VPN (Cisco ASA running AnyConnect) to enforce strict authentication and authorization. But VPN always felt clunky: it’s difficult to set up, maintain (securely), and scale on the server side. Each new employee we onboarded needed to learn how to configure their client. But migration takes time and involves many different teams. While we migrated services one by one, we focused on the high priority services first and worked our way down. Until the last service is moved to Access, we still maintain our VPN, keeping it protected with Spectrum.

Some of our services didn’t run over HTTP or other Access-supported protocols, and still required the use of the VPN: source control (git+ssh) was a particular sore spot. If any of our developers needed to commit code they’d have to fire up the VPN to do so. To help in our new-found goal to kill the pinata, we introduced support for SSH over Access, which allowed us to replace the VPN as a protection layer for our source control systems.

Over the years, we’ve been whittling away at our services, one-by-one. We’re nearly there, with only a few niche tools remaining behind the VPN and not behind Access. As of this year, we are no longer requiring new employees to set up VPN as part of their company onboarding! We can see this in our Access logs, with more users logging into more apps every month:

Migrating from VPN to Access

During this transition period from VPN to Access, we’ve had to keep our VPN service up and running. As VPN is a key tool for people doing their work while remote, it’s extremely important that this service is highly available and performant.

Enter Spectrum: our DDoS protection and performance product for any TCP and UDP-based protocol. We put Spectrum in front of our VPN very early on and saw immediate improvement in our security posture and availability, all without any changes in end-user experience.

With Spectrum sitting in front of our VPN, we now use the entire Cloudflare edge network to protect our VPN endpoints against DDoS and improve performance for VPN end-users.

Setup was a breeze, with only minimal configuration needed:

Migrating from VPN to Access

Cisco AnyConnect uses HTTPS (TCP) to authenticate, after which the actual data is tunneled using a DTLS encrypted UDP protocol.

Although configuration and setup was a breeze, actually getting it to work was definitely not. Our early users quickly noted that although authenticating worked just fine, they couldn’t actually see any data flowing through the VPN. We quickly realized our arch nemesis, the MTU (maximum transmission unit) was to blame. As some of our readers might remember, we have historically always set a very small MTU size for IPv6. We did this because there might be IPv6 to IPv4 tunnels in between eyeballs and our edge. By setting it very low we prevented PTB (packet too big) packets from ever getting sent back to us, which causes problems due to our ECMP routing inside our data centers. But with a VPN, you always increase the packet size due to the VPN header. This means that the 1280 MTU that we had set would never be enough to run a UDP-based VPN. We ultimately settled on an MTU of 1420, which we still run today and allows us to protect our VPN entirely using Spectrum.

Over the past few years this has served us well, knowing that our VPN infrastructure is safe and people will be able to continue to work remotely no matter what happens. All in all this has been a very interesting journey, whittling down one service at a time, getting closer and closer to the day we can officially retire our VPN. To us, Access represents the future, with Spectrum + VPN to tide us over and protect our services until they’ve migrated over. In the meantime, as of the start of 2020, new employees no longer get a VPN account by default!

Dogfooding from Home: How Cloudflare Built our Cloud VPN Replacement

Post Syndicated from Evan Johnson original https://blog.cloudflare.com/dogfooding-from-home/

Dogfooding from Home: How Cloudflare Built our Cloud VPN Replacement

Dogfooding from Home: How Cloudflare Built our Cloud VPN Replacement

It’s never been more crucial to help remote workforces stay fully operational — for the sake of countless individuals, businesses, and the economy at large. In light of this, Cloudflare recently launched a program that offers our Cloudflare for Teams suite for free to any company, of any size, through September 1. Some of these firms have been curious about how Cloudflare itself uses these tools.

Here’s how Cloudflare’s next-generation VPN alternative, Cloudflare Access, came to be.

Rewind to 2015. Back then, as with many other companies, all of Cloudflare’s internally-hosted applications were reached via a hardware-based VPN. When one of our on-call engineers received a notification (usually on their phone), they would fire up a clunky client on their laptop, connect to the VPN, and log on to Grafana.

It felt a bit like solving a combination lock with a fire alarm blaring overhead.

Dogfooding from Home: How Cloudflare Built our Cloud VPN Replacement

But for three of our engineers enough was enough. Why was a cloud network security company relying on clunky on-premise hardware?

And thus, Cloudflare Access was born.

A Culture of Dogfooding

Many of the products Cloudflare builds are a direct result of the challenges our own team is looking to address, and Access is a perfect example. Development on Access originally began in 2015, when the project was known internally as EdgeAuth.

Initially, just one application was put behind Access. Engineers who received a notification on their phones could tap a link and, after authenticating via their browser, they would immediately have access to the key details of the alert in Grafana. We liked it a lot — enough to get excited about what we were building.

Access solved a variety of issues for our security team as well. Using our identity provider of choice, we were able to restrict access to internal applications at L7 using Access policies. This once onerous process of managing access control at the network layer with a VPN was replaced with a few clicks in the Cloudflare dashboard.

Dogfooding from Home: How Cloudflare Built our Cloud VPN Replacement

After Grafana, our internal Atlassian suite including Jira and Wiki, and hundreds of other internal applications, the Access team began working to support non-HTTP based services. Support for git allowed Cloudflare’s developers to securely commit code from anywhere in the world in a fully audited fashion. This made Cloudflare’s security team very happy. Here’s a slightly modified example of a real authentication event that was generated while pushing code to our internal git repository.

Dogfooding from Home: How Cloudflare Built our Cloud VPN Replacement

It didn’t take long for more and more of Cloudflare’s internal applications to make their way behind Access. As soon as people started working with the new authentication flow, they wanted it everywhere. Eventually our security team mandated that we move our apps behind Access, but for a long time it was totally organic: teams were eager to use it.

Incidentally, this highlights a perk of utilizing Access: you can start by protecting and streamlining the authentication flows for your most popular internal tools — but there’s no need for a wholesale rip-and-replace. For organizations that are experiencing limits on their hardware-based VPNs, it can be an immediate salve that is up and running after just one setup call with a Cloudflare onboarding expert (you can schedule a time here).

That said, there are some upsides to securing everything with Access.

Supporting a Global Team

VPNs are notorious for bogging down Internet connections, and the one we were using was no exception. When connecting to internal applications, having all of our employees’ Internet connections pass through a standalone VPN was a serious performance bottleneck and single point of failure.

Dogfooding from Home: How Cloudflare Built our Cloud VPN Replacement

Cloudflare Access is a much saner approach. Authentication occurs at our network edge, which extends to 200 cities in over 90 countries globally. Rather than having all of our employees route their network traffic through a single network appliance, employees connecting to internal apps are connecting to a data center just down the road instead.

As we support a globally-distributed workforce, our security team is committed to protecting our internal applications with the most secure and usable authentication mechanisms. With Cloudflare Access we’re able to rely on the strong two-factor authentication mechanisms of our identity provider, which was much more difficult to do with our legacy VPN.

With Cloudflare Access we’re able to rely on the strong two-factor authentication mechanisms of our identity provider, which was much more difficult to do with our legacy VPN.

On-Boarding and Off-Boarding with Confidence

One of the trickiest things for any company is ensuring everyone has access to the tools and data they need — but no more than that. That’s a challenge that becomes all the more difficult as a team scales. As employees and contractors leave, it is similarly essential to ensure that their permissions are swiftly revoked.

Managing these access controls is a real challenge for IT organizations around the world — and it’s greatly exacerbated when each employee has multiple accounts strewn across different tools in different environments. Before using Access, our team had to put in a lot of time to make sure every box was checked.

Now that Cloudflare’s internal applications are secured with Access, on- and offboarding is much smoother. Each new employee and contractor is quickly granted rights to the applications they need, and they can reach them via a launchpad that makes them readily accessible. When someone leaves the team, one configuration change gets applied to every application, so there isn’t any guesswork.

Access is also a big win for network visibility. With a VPN, you get minimal insight into the activity of users on the network – you know their username and IP address. but that’s about it. If someone manages to get in, it’s difficult to retrace their steps.

Cloudflare Access is based on a zero-trust model, which means that every packet is authenticated. It allows us to assign granular permissions via Access Groups to employees and contractors. And it gives our security team the ability to detect unusual activity across any of our applications, with extensive logging to support analysis. Put simply: it makes us more confident in the security of our internal applications.

But It’s Not Just for Us

With the massive transition to a remote work model for many organizations, Cloudflare Access can make you more confident in the security of your internal applications — while also driving increased productivity in your remote employees. Whether you rely on Jira, Confluence, SAP or custom-built applications, it can secure those applications and it can be live in minutes.

Cloudflare has made the decision to make Access completely free to all organizations, all around the world, through September 1. If you’d like to get started, follow our quick start guide here:
Or, if you’d prefer to onboard with one of our specialists, schedule a 30 minute call at this link: calendly.com/cloudflare-for-teams/onboarding?month=2020-03

Work-from-Home Security Advice

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2020/03/work-from-home_.html

SANS has made freely available its “Work-from-Home Awareness Kit.”

When I think about how COVID-19’s security measures are affecting organizational networks, I see several interrelated problems:

One, employees are working from their home networks and sometimes from their home computers. These systems are more likely to be out of date, unpatched, and unprotected. They are more vulnerable to attack simply because they are less secure.

Two, sensitive organizational data will likely migrate outside of the network. Employees working from home are going to save data on their own computers, where they aren’t protected by the organization’s security systems. This makes the data more likely to be hacked and stolen.

Three, employees are more likely to access their organizational networks insecurely. If the organization is lucky, they will have already set up a VPN for remote access. If not, they’re either trying to get one quickly or not bothering at all. Handing people VPN software to install and use with zero training is a recipe for security mistakes, but not using a VPN is even worse.

Four, employees are being asked to use new and unfamiliar tools like Zoom to replace face-to-face meetings. Again, these hastily set-up systems are likely to be insecure.

Five, the general chaos of “doing things differently” is an opening for attack. Tricks like business email compromise, where an employee gets a fake email from a senior executive asking him to transfer money to some account, will be more successful when the employee can’t walk down the hall to confirm the email’s validity — and when everyone is distracted and so many other things are being done differently.

Worrying about network security seems almost quaint in the face of the massive health risks from COVID-19, but attacks on infrastructure can have effects far greater than the infrastructure itself. Stay safe, everyone, and help keep your networks safe as well.

Cloudflare During the Coronavirus Emergency

Post Syndicated from Matthew Prince original https://blog.cloudflare.com/cloudflare-during-the-coronavirus-emergency/

Cloudflare During the Coronavirus Emergency

This email was sent to all Cloudflare customers a short while ago

From: Matthew Prince
Date: Thu, Mar 12, 2020 at 4:20 PM
Subject: Cloudflare During the Coronavirus Emergency

We know that organizations and individuals around the world depend on Cloudflare and our network. I wanted to send you a personal note to let you know how Cloudflare is dealing with the Coronavirus emergency.

First, the health and safety of our employees and customers is our top priority. We have implemented a number of sensible policies to this end, including encouraging many employees to work from home. This, however, hasn’t slowed our operations. Our network operations center (NOC), security operations center (SOC), and customer support teams will remain fully operational and can do their jobs entirely remote as needed.

Second, we are tracking Internet usage patterns globally. As more people work from home, peak traffic in impacted regions has increased, on average, approximately 10%. In Italy, which has imposed a nationwide quarantine, peak Internet traffic is up 30%. Traffic patterns have also shifted so peak traffic is occurring earlier in the day in impacted regions. None of these traffic changes raise any concern for us. Cloudflare’s network is well provisioned to handle significant spikes in traffic. We have not seen, and do not anticipate, any impact to our network’s performance, reliability, or security globally.

Third, we are monitoring for any changes in cyberthreats. While we have seen more phishing attacks using the Coronavirus as a lure, we have not seen any significant increase in attack traffic or new threats. Again, our SOC remains fully operational and is continuously monitoring for any new security threats that may emerge.

Finally, we recognize that this emergency has put strain on the infrastructure of companies around the world as more employees work from home. On Monday, I wrote about how we are making our Cloudflare for Teams product, which helps support secure and efficient remote work, free for small businesses for at least the next six months:


As the severity of the emergency has become clearer over the course of this week, we decided to extend this offer to help any business, regardless of size. The healthy functioning of our economy globally depends on work continuing to get done, even as people need to do that work remotely. If Cloudflare can do anything to help ensure that happens, I believe it is our duty to do so.

If you are already a Cloudflare for Teams customer, we have removed the caps on usage during this emergency so you can scale to whatever number of seats you need without additional cost. If you are not yet using Cloudflare for Teams, and if you or your employer are struggling with limits on the capacity of your existing VPN or Firewall, we stand ready to help and have removed the limits on the free trials of our Access and Gateway products for at least the next six months. Cloudflare employees around the world have volunteered to run no-cost onboarding sessions so you can get set up quickly and ensure your business’ continuity.

Details: https://developers.cloudflare.com/access/about/coronavirus-emergency/
Sign up for an onboarding session: https://calendly.com/cloudflare-for-teams/onboarding

Thank you for being a Cloudflare customer. These are challenging times but I want you to know that we stand ready to help however we can. We understand the critical role we play in the functioning of the Internet and we are continually humbled by the trust you place in us. Together, we can get through this.

Matthew Prince
Co-founder & CEO


Open sourcing our Sentry SSO plugin

Post Syndicated from Sam Rhea original https://blog.cloudflare.com/open-sourcing-our-sentry-sso-plugin/

Open sourcing our Sentry SSO plugin

Cloudflare Access, part of Cloudflare for Teams, replaces legacy corporate VPNs with Cloudflare’s global network. Using your existing identity provider, Access enables your end users to login from anywhere — without a clunky agent or traffic backhaul through a centralized appliance or VPN.

Today, we are open sourcing a plugin that continues to improve that experience by making it easier for teams to use Cloudflare Access with one of the software industry’s most popular engineering tools, Sentry.

What is Sentry?

Sentry is an application that helps software teams find and diagnose errors in their products. We use Sentry here at Cloudflare. When you encounter an error when using a Cloudflare product, like our dashboard, we log that event. We then use Sentry to determine what went wrong.

Sentry can categorize and roll up errors, making it easy to identify new problems before investigating them with the tool’s event logging. Engineering managers here can use the dashboards to monitor the health of a new release. Product managers often use those reports as part of prioritizing what to fix next. Engineers on our team can dig into the individual errors as they release a fix.

Sentry is available in two forms: a SaaS model and a self-hosted version. Both modes give engineering teams comprehensive insight into the behavior of their deployed applications and the issues their users encounter.

Connecting users to Sentry

Organizations can deploy the self-hosted version on-premise or in a cloud environment they control. However, they still need to create a secure way to allow their teams to connect to the app.

Historically, most opt for a VPN to solve that challenge. End users outside of the office need to configure a VPN client on their laptop and try to login with credentials that are often different from the ones used for a corporate SSO. Administrators had to make sure their VPN appliance could scale for a few users, but with most in the office, the VPN was a serious inconvenience for a smaller set of users.

Over the last few years, that group of users working outside of the office has grown. The outbreak of COVID-19 is accelerating that growth significantly. Users are working from BYOD laptops, mobile phones, and in unfamiliar networks that all struggle with a VPN. Even worse, a VPN has a load limit because it relies on an actual appliance (whether virtual or physical hardware). Organizations can attempt to stress test their VPN, but will always have a limit that administrators need to continuously monitor.

Cloudflare Access gives administrators the scale of Cloudflare’s global network and provides end users with a SaaS-like experience that just works from any device or network. When teams secure Sentry with Cloudflare Access, end users visit the hostname of the application, login with their identity provider, and are redirected from Cloudflare’s edge to the app if they have permission to reach it.

However, in the case of an app like Sentry, end users need to login one more time to the application itself. That small step adds real friction, which Access can now solve through this open source plugin.

JWT Security with Cloudflare for Teams

When a user logs in to their identity provider when connecting to an application protected by Access, Cloudflare signs a JSON Web Token (JWT).

Open sourcing our Sentry SSO plugin

Cloudflare Access uses that JWT, and its contents, to confirm a user identity before allowing or denying access to sensitive resources. Cloudflare securely creates these through the OAUTH or SAML integration between Cloudflare Access and the configured identity provider. Each JWT consists of three Base64-URL strings: the header, the payload, and the signature.

  • The header defines the cryptographic operation that encrypts the data in the JWT.
  • The payload consists of name-value pairs for at least one and typically multiple claims, encoded in JSON. For example, the payload can contain the identity of a user
  • The signature allows the receiving party to confirm that the payload is authentic.

The token is signed using a public private key pair and saved in the user’s browser. Inside of that token, we store the following details in addition to some general metadata:

  • User identity: typically the email address of the user retrieved from your identity provider.
  • Authentication domain: the domain that signs the token. For Access, we use “example.cloudflareaccess.com” where “example” is a subdomain you can configure.
  • Audience: The domain of the application you are attempting to reach.
  • Expiration: the time at which the token is no longer valid for use.

When a request is made to an application behind Access, Cloudflare looks for the presence of that token. If available, we decrypt it, validate its authenticity, and then read the payload. If the payload contains information about a user who should be able to reach the application, we send their request to an origin.

The Sentry plugin takes that JWT and reuses it, instead of prompting the visitor to login again with separate credentials. The plugin parses the user identity, checks it against the directory of users in Sentry, and maps that token to a Sentry profile and its assigned permissions.

All of this is seamless to the end user and takes just a few milliseconds. The user is instantly redirected to the application, fully authenticated, and only needs to remember their SSO login. Administrators now have one fewer set of credentials to worry about managing and the associated onboarding and offboarding.

Building your own SSO plugin

We believe that the JSON Web Token is a simple and efficient method for sending identity. Applications that use JWTs for authorization only need to support the JWT standard, instead of attempting to integrate with different versions of SAML or other formats like OIDC and OAUTH. A JWT is also information dense and built in a format, JSON, that can be easily parsed by the target application.

Some products, like Redash, already have native support for JWT integration. The Sentry plugin we built joins our Atlassian plugin as both options to extend support to those apps, but also examples that can be used for integration with other products. Other teams, like Auth0, have also published materials to add JWT integration to legacy apps.

What’s next?

Cloudflare Access is available on every Cloudflare account and 5 free seats are included by default. You can follow these instructions to get started.

If you are a small business, you can sign up for the Cloudflare for Teams program right now at the link below.


How Replicated Developers Develop Remotely

Post Syndicated from Guest Author original https://blog.cloudflare.com/how-replicated-secured-our-remote-dev-environment-with-cloudflare-access/

How Replicated Developers Develop Remotely

This is a guest post by Marc Campbell and Grant Miller, co-founders of Replicated.

How Replicated Developers Develop Remotely

Replicated is a 5-year old infrastructure software company working to make it easy for businesses to install and operate third party software. We don’t want you to have to send your data to a multi-tenant SaaS provider just to use their services. Our team is made up of twenty-two people distributed throughout the US. One thing that’s different about Replicated is our developers don’t actually store or execute code on their laptops; all of our development happens on remote instances in the cloud.

Our product, KOTS, runs in Kubernetes and manages the lifecycle of 3rd-party applications in the Kubernetes cluster. Building and validating the product requires a developer to have access to a cluster. But as we started to hire more and more engineers it became ridiculous to ask everyone to run their own local Kubernetes cluster. We needed to both simplify and secure our setup to allow every engineer to run their environment in the cloud, and we needed to do it in a way which was seamless and secure.

Previous Dev Environments with Docker for Mac

We started with each developer building their own local environments, using whatever tools they were comfortable with. Our first attempt to build a standard development environment that works for our engineering team was to use Docker for Mac and its built-in Kubernetes distribution. We would buy the best MacBook Pros available (16 GB, then 32 GB, now 64 GB), and everyone would have the entire stack running on their laptop.

This worked pretty well, except that there was a set of problems that our engineers would continue to hit–battery life was terrible because of the constant CPU usage, Docker For Mac was different from “real Kubernetes” in some meaningful ways, and Docker for Mac’s built-in K8s regularly would just sometimes stop working and the developer would need to uninstall and reinstall the entire stack. It was miserable.

We’d lose hours every week from engineers troubleshooting their local environments. When a front end engineer (who wasn’t expected to be a Kubernetes expert) would have issues, they’d need to pair and get help from a backend engineer; consuming not just one but two people’s valuable time.

We needed something better.

To The Cloud

Rather than running Docker locally, we now create an instance in Google Cloud for each developer. These instances have no public IP and are based on our machine image which has all of our prerequisites installed. This includes many tools, including a Kubernetes distribution that’s completely local to the server. We run a docker registry in each developer’s cluster as a cluster add-on. The cloud server has a magical tool called cloudflared running on it that replaces all of the network configuration and security work we would otherwise have had to do.‌‌

Cloudflared powers Argo Tunnel. When it starts, cloudflared creates four secure HTTP/2 tunnels to two Cloudflare data centers. When a request comes in for a development machine, Cloudflare routes that request over one of those tunnels directly to the machine running that developer’s environment. For example, my hostname is “marc.repl.dev”. Whenever I connect to that, from anywhere on earth, Cloudflare will see that I reach my development environment securely. If I need to spin up a new development environment, there is no configuration to do, wherever is running cloudflared with the appropriate credentials will receive the traffic. This all works on any cloud and in any cloud region.

‌‌This configuration has several advantages over a traditional deployment. For one, the server does not have a public IP and we don’t need to have any ports open in the Google Load Balancer, including for SSH. The only way to connect to these servers is through the Argo Tunnel, secured by Cloudflare Access. Access provides a BeyondCorp-style method of authentication, this ensures that the environment can be reached from anywhere in the world without the use of a VPN.

How Replicated Developers Develop Remotely

BeyondCorp is an elaborate way of saying that all our authentication is managed in a single place. We can write a policy which defines which machines a user should have access to and trust it will be applied everywhere. This means rather than managing SSH certificates which are hard to revoke and long-living, we can allow developers to login with the same Google credentials we use everywhere else! Should, knock on wood, a developer leave, we can revoke those credentials instantly; no more worrying what public keys they still might have lying around.

What happens on the developer’s machines?

Through Argo Tunnel and Access we now have the ability to connect to our new development instances, but that isn’t enough to allow our engineers to work. They need to be able to write and execute code on that remote machine in a seamless way. To solve that problem we turned to the Remote SSH extension for VS Code. In the words of the documentation for that project:

The Visual Studio Code Remote SSH extension allows you to open a remote folder on any remote machine, virtual machine, or container with a running SSH server and take full advantage of VS Code’s feature set. Once connected to a server, you can interact with files and folders anywhere on the remote filesystem.

With Remote SSH, VS Code seamlessly reads and writes files to the developer’s remote server. When a developer opens a project, it feels local and seamless, but everything is authenticated by Access and proxied through Argo over SSH. Our developers can travel anywhere in the world, and trust their development environment will be accessible and fast.

Locally, a developer has a .ssh/config file to define local ports to forward through the SSH connection to a port that’s only available on the remote server. For example, my .ssh/config file contains:‌‌

Host marc.repl.dev

HostName marc.repl.dev

User marc‌‌

LocalForward 8080

LocalForward 8005

To build and execute code our developers open the embedded terminal in VS Code. This automatically connects them to the remote server. We use skaffold, a Kubernetes CLI for local development. A simple skaffold dev starts the stack on their remote machine which feels local because it’s all happening inside VS Code. Once it’s started, the developer can access localhost in their browser to view the results of their work by visiting http://localhost:8080. The SSH config above will forward this traffic to port 30080 on the remote server. Port 30080 on the remote server is a NodePort configured in the local cluster, that has the web server running in it. All of our APIs and web servers have static NodePorts for local development environments.

Now, when a developer starts at Replicated, their first day (or even week) isn’t consumed by setting up the development environment–now it takes less than an hour. We have a Terraform script that makes it easy to replace any one of our developer’s machines in seconds.

The Aftermath

All developers at Replicated have now been using this environment for nine months. We haven’t eliminated the problems that occasionally come up where Kubernetes isn’t playing nicely, or Docker uses too much disk space. However, these problems do occur much less frequently than they did on Docker for Mac. We now have two new options that weren’t easily available when everyone ran their environment locally.

First, a backend engineer can just ssh through the Argo Tunnel into the other developers server to troubleshoot and help. Every development environment has become a collaborative place. This is great when two engineers aren’t in the same room.  Also, we’re less attached to our development environments–if my server isn’t working properly for unknown reasons, instead of troubleshooting it for hours, I can delete it and get a new clean one.

Some additional benefits include:

  • Developers can have multiple envs easily (to try out a new k8s version, for example)
  • Battery life is awesome again on laptops
  • We don’t need the biggest and most powerful laptops anymore (Hello Chromebooks and Tablets)
  • Developers can choose their local OS and environment (MacOS, Windows, Linux) because they are all supported, as long as SSH is supported.
  • Code does not live on a developer laptop; it doesn’t travel with them to coffee shops and other insecure places. This is great for security purposes–a lost laptop no longer means the codebase is out there with it.

How To

Beyond just telling you what we did, we’d like to show you how to replicate it for yourself! This assumes you have a domain which is already configured to use Cloudflare.

  1. Create an instance to represent your development environment in the cloud of your choice.


gcloud compute instances create my-dev-universe


2.   Configure your instance to run cloudflared when it starts up, and give it a helpful hostname like dev.mysite.com.‌‌


sudo apt-get install cloudflare/cloudflare/cloudflared

cat “hostname: dev.mysite.com\n” > ~/.cloudflared/config.yml

cloudflared login

sudo cloudflared service install


3.  Write an Access policy to allow only you to access your machine‌‌

How Replicated Developers Develop Remotely

‌4. Configure your local machine to SSH via Cloudflare:‌‌


sudo apt-get install cloudflare/cloudflare/cloudflared

cloudflared access ssh-config –hostname dev.mysite.com –short-lived-cert >> ~/.ssh/config


4. Install VS Code and the Remote Development extension pack

5. In VS Code select ‘Remote-SSH: Connect to Host…’ from the Command Palette and enter [email protected]. A browser window will open where you will be prompted to login with the identity provider you configured with Cloudflare.

6. You’re done! If you select File > Open you will be seeing files on your remote machine. The embedded terminal will also execute code on that remote machine.

7. Once you’re ready to get a production-ready setup for your team, take a look at the instructions we share with our team.


There is no doubt that the world is becoming more Internet-connected, and that deployment environments are becoming more complex. It stands to reason that it’s only a matter of time before all software development happens through and in concert with the Internet.

While it might not be the best solution for every team, it has resulted in a dramatically better experience for Replicated and we hope it does for you as well.

How to get started‌‌

‌‌Replicated develops remotely with Cloudflare Access, a remote access gateway that helps you secure access to internal applications and infrastructure without a VPN.

Effective until September 1, 2020, Cloudflare is making Access and other Cloudflare for Teams products free to small businesses. We’re doing this to help ensure that small businesses that implement work from home policies in order to combat the spread of the Coronavirus (COVID-19) can ensure business continuity.

‌You can learn more and apply at cloudflare.com/smallbusiness now.

How to Build a Highly Productive Remote Team (or Team of Contractors) with Cloudflare for Teams

Post Syndicated from Lane Billings original https://blog.cloudflare.com/how-to-build-a-highly-productive-remote-team-or-team-of-contractors-with-cloudflare-for-teams/

How to Build a Highly Productive Remote Team (or Team of Contractors) with Cloudflare for Teams

Much of IT has been built on two outdated assumptions about how work is done. First, that employees all sit in the same building or branch offices. Second, that those employees will work full-time at the same company for years.

Both of these assumptions are no longer true.

Employees now work from anywhere. In the course of writing this blog post, I opened review tickets in our internal JIRA from my dining table at home. I reviewed internal wiki pages on my phone during my commute on the train. And I spent time reviewing some marketing materials in staging in our CMS.

In a past job, I would have suffered trying to connect to these tools through a VPN. That would have slowed down my work on a laptop and made it nearly impossible to use a phone to catch up on my commute.

The second challenge is ramp-up. I joined Cloudflare a few months ago. As a member of the marketing team, I work closely with our product organization and there are several dozen tools that I need to do that.

I’m hardly alone. The rise of SaaS and custom internal applications means that employees need access to all kinds of tools to effectively do their job. The increasing prevalence of contractors and part-time employees is compounding the challenge of how to get employees productive. On-boarding (and off-boarding) is now not an occasional thing, but has become a regular rhythm of how companies operate.

All these factors are combining to cause a bigger question: how can I make teams that reflect the new modern workforce — often remote, and increasingly not the traditional full time, permanent employee — as productive as possible?

Step one: put the VPN on a performance improvement plan

We’ve blogged extensively about our own troubles with VPNs. As we became a complex, multinational organization made up of contractors and full-time employees, the private network we deployed to host internal applications began to slow our teams down. We built Cloudflare Access to address our own challenges with the VPN, and since then hundreds of customers have used it to accelerate access for their remote workforces.

How to Build a Highly Productive Remote Team (or Team of Contractors) with Cloudflare for Teams

India’s largest B2B e-commerce platform, Udaan, is one example. They used Access to avoid ever having to deploy a VPN in the first place. As Udaan grew to new locations around the world, their IT team needed fast ways to give access to the thousands of users — including contractors, employees, interns and vendors — that needed to connect to their internal systems.

Now that their internal applications are protected with Cloudflare, Udaan’s IT team doesn’t need to spend time manually onboarding contractors and issuing them corporate accounts. And logging into Udaan’s tools, whether they’re SaaS apps or private applications, looks and feels the same every time, for every user.

How to Build a Highly Productive Remote Team (or Team of Contractors) with Cloudflare for Teams

“VPNs are frustrating and lead to countless wasted cycles for employees and the IT staff supporting them,” said Amod Malviya, Cofounder and CTO, Udaan.  Furthermore, conventional VPNs can lull people into a false sense of security. With Cloudflare Access, we have a far more reliable, intuitive, secure solution that operates on a per user, per access basis. I think of it as Authentication 2.0 — even 3.0”

Cloudflare Access can help speed up remote teams by replacing VPNs with Cloudflare’s network. Instead of placing internal tools on a private network, teams can deploy them in any environment, including hybrid or multi-cloud models, and secure them consistently with Cloudflare’s network.  Remote teams get work done faster without having to deal with a VPN client, and IT teams spend less time troubleshooting their VPN issues.

Step two: make tools easier to find

High performing remote teams get new employees started fast. That starts with day-one access to the right tools. If you’re like me and you recently joined a new organization, you know how hard it can be to find the right applications you need to do your job. I am drowning in an ocean of new productivity tools.

App launchpads were designed to be a life-raft in the tools ocean. They make discovering apps easier by bringing every application a user can access into one easy, graphical dashboard. But they’re hard for IT teams to customize for different types of users with different permission levels (intern/contractor/full-time), and often not comprehensive of every kind of app (internal/SaaS).

Cloudflare Access’ App Launch is a dashboard for all the applications protected by Access. Once enabled, end users can login and connect to every app behind Access with a single click.  IT teams that are setting up contractors can send contractors a custom launchpad of everything they need to access on day one.

How to Build a Highly Productive Remote Team (or Team of Contractors) with Cloudflare for Teams

When administrators secure an application with Access, any request to the hostname of that application stops at Cloudflare’s network first. Once there, Cloudflare Access checks the request against the list of users who have permission to reach the application.

To check identity, Access relies on the identity provider that the team already uses. Access integrates with providers like OneLogin, Okta, AzureAD, G Suite and others to determine who a user is. If the user has not logged in yet, Access will prompt them to do so at the identity provider configured.

Step 3: fast-track your contractors

Modern remote teams are made up of whatever combination of people can get online and get the work done. That means many different kinds of users are working together in the same tools –full-time employees, contractors, freelancers, vendors and partners.

IT models predicated on full-time workforces imagined identifying users as a straight line process, where users could be identified and validated against one source of truth – the corporate directory. The old model breaks down when users join organizations temporarily to work on isolated projects, and you need to figure out how to authenticate them based on their organizational identity, not yours.

In response, many organizations deploy VPNs to temporary users, scotch-tape together federations between multiple SSO providers, or even have administrators spend hours issuing contracted users new corporate identities to complete one-off projects.

Meanwhile, contractors waste valuable cycles getting set up with the tools they need, and feel like second-class citizens in the IT hierarchy.

How to Build a Highly Productive Remote Team (or Team of Contractors) with Cloudflare for Teams

Cloudflare Access prevents contractor onboarding slowdown by simultaneously integrating with multiple identity providers, including popular services like Gmail or GitHub that do not require corporate subscriptions.

External users login with these accounts and still benefit from the same ease-of-use available to internal employees. Meanwhile, administrators avoid the burden in legacy deployments that require onboarding and offboarding new accounts for each project.

How to get started – at no cost

Cloudflare for Teams lets your team use all the same features to stay productive from anywhere in the world.

Effective until September 1, 2020, we’re making Cloudflare for Teams products free to small businesses. We’re doing this to help ensure that small businesses that implement work from home policies in order to combat the spread of the Coronavirus (COVID-19) can ensure business continuity.

You can learn more and apply at cloudflare.com/smallbusiness now.

Cloudflare for Teams Free for Small Businesses During Coronavirus Emergency

Post Syndicated from Matthew Prince original https://blog.cloudflare.com/cloudflare-for-teams-free-for-small-businesses-during-coronavirus-emergency/

Cloudflare for Teams Free for Small Businesses During Coronavirus Emergency

Cloudflare for Teams Free for Small Businesses During Coronavirus Emergency

There are a lot of people and businesses worldwide that are currently suffering, so I don’t want to waste any time in getting to the point.

Beginning today, we are making our Cloudflare for Teams products free to small businesses around the world. Teams enables remote workers to operate securely and easily. We will continue this policy for at least the next 6 months. We’re doing this to help ensure that small businesses that implement work from home policies in order to combat the spread of the virus can ensure business continuity. You can learn more and apply at: https://www.cloudflare.com/smallbusiness

We’ve also helped launch an online hub where small businesses can see technology services available to them for free or a substantial discount from multiple companies, during the Coronavirus Emergency: https://openforbusiness.org

To understand more about why we’re doing this, read on.

The IT Strain of WFH

We have a team at Cloudflare carefully monitoring the spread of the SARS-Coronavirus-2, which is responsible for the COVID-19 respiratory disease. Like at many other companies, we have heeded the advice of medical professionals and government agencies and are increasingly allowing employees to work from home in impacted regions in order to hopefully help slow the spread of the disease.

While this is prudent advice to help control the spread of the disease, employees working from home put a different load on a company’s IT resources than if they are working from the office. In-person meetings are instead held online, so you need to ensure your video conferencing systems are up for the task. Critical documents can’t be signed in person, so electronic signature systems need to be in place. There’s an increased importance on online chat and other communication tools.

And, importantly, the systems that ensure online authorized access to these tools can no longer use the physical location of an employee as evidence they are authorized to use a service.

WFH Strains IT Security

We’ve seen some large companies struggle in ways both serious and silly with increased loads on their traditional firewall and VPN infrastructures over the last week.

Large organizations, undoubtedly, can work through these issues by either increasing the number of licenses for their firewalls and VPNs or moving to a more modern, cloud-based solution. What’s been concerning to us is the number of small businesses that don’t have the ability to quickly provision the resources they need to support their employees when they’re not physically in the office.

What We’re Seeing

The story that hit home to me came last week when I heard about a small business who had reached out to us. The company has approximately 100 employees in a region hard-hit by viral infections and thousands of partners who use their platform. They, responsibly, allowed their employees to work from home. Unfortunately, their small office VPN was limited in terms of the number of simultaneous users as well as capacity. Their outsourced IT team said getting a new one up and running would take at least a week. And, at a time when travel bookings were already waning, the owner was legitimately concerned that his business would not survive this crisis.

I happened to be sitting with a group of our sales engineers over lunch last week when I heard this story. They were proud that we’d been able to offer Cloudflare for Teams as a solution to quickly replace the travel agency’s VPN. And that’s great—the owner of the travel agency was thrilled—but it still felt like we should be doing more.

I spent some time digging into recent inquiries for Cloudflare for Teams coming from small businesses and found that the travel agency was hardly alone. Small businesses around the world are struggling to maintain some semblance of business continuity as increasingly their employees aren’t physically coming into the office. While firewalls and VPNs were hardly their only concern, the limitations they imposed were becoming real threats to business continuity.

The Fragility of Small Businesses

Small businesses are the lifeblood of most countries’ economies. In the United States, for instance, small businesses employ half of all non-government employees. They are responsible for the creation of two-thirds of net new jobs. Unfortunately, they are much more vulnerable to even minor interruptions in their operations. Oftentimes their margins are so thin that any significant new expense or reduction in revenue can cause them to fail.

Today Cloudflare makes most of our money selling to large enterprises. But serving small businesses has always been in our DNA. We began as a small business ourselves and spent our early years providing the tools previously available only to the big guys to every individual developer and small business. We wouldn’t be the company we are today if small businesses hadn’t trusted us in our early years.

So while the impact of the Coronavirus is being felt by businesses large and small, I am worried the impact on small businesses could be especially devastating. Small businesses have always been there for us and we want to be there for them during this time of increased strain, therefore today we’re announcing two initiatives:

Free Cloudflare for Teams

First, we are making Cloudflare for Teams available to small businesses worldwide for free for at least the next six months. We will evaluate the situation in six months and make a determination about whether we will extend the length of the free offer.

We are using the US Small Business Administration’s definition of a small business to define what businesses qualify, but the offer is not limited to US companies. The Coronavirus is an issue for small businesses globally and we have an extensive global network that can serve customers worldwide.

To apply, visit: https://www.cloudflare.com/smallbusiness

Our team is standing by and will move quickly evaluating applications.

Moreover, since small businesses often don’t have sophisticated IT teams, Cloudflare team members from all over the world have volunteered to host onboarding sessions to help small businesses get setup quickly and correctly. We’ve worked hard to make Cloudflare for Teams easy for any business to be able to use, but we understand that it can still be intimidating if your expertise isn’t IT. Our team stands ready to help.

The Open for Business Hub

Second, we realize that Cloudflare for Teams solves only one little part of a small business’ challenges as their employees increasingly work from home. They also need communication, video conferencing, collaboration, document management, and other IT resources. We don’t provide them all, but we know the leaders at a lot of companies who do.

Cloudflare for Teams Free for Small Businesses During Coronavirus Emergency

I spent the weekend talking with other companies that I admire and that provide cloud-based solutions that could help solve the challenges many businesses are currently facing. Many shared the same concerns that we had about the fragility of small businesses and wanted to help. Together we are helping launch a hub of resources for small businesses working to ensure business continuity over the months to come: https://openforbusiness.org/

The hub features free and deeply discounted services for small businesses from several technology companies. And I expect more will step up to this challenge over the days to come. To request inclusion, companies can email: [email protected].

We’re In This Together

The news of the spread of the Coronavirus has made it clear it is no longer business as usual for any business worldwide. Every responsible business leader spent the weekend worried about how they’re going to get through the weeks and months ahead: ensuring their employees’ safety, delivering for their customers, and protecting their business. I believe we have a duty to step up where we can to help each other out during times of stress like the one we’re in. Together, we can get through this.

How Cloudflare keeps employees productive from any location

Post Syndicated from Sam Rhea original https://blog.cloudflare.com/how-cloudflare-keeps-employees-productive-from-any-location/

How Cloudflare keeps employees productive from any location

Cloudflare employs more than 1,200 people in 13 different offices and maintains a network that operates in 200 cities. To do that, we used to suffer through a traditional corporate VPN that backhauled traffic through a physical VPN appliance. It was, frankly, horrible to work with as a user or IT person.

With today’s mix of on-prem, public cloud and SaaS and a workforce that needs to work from anywhere, be it a coffee shop or home, that model is no longer sustainable. As we grew in headcount, we were spending too much time resolving VPN helpdesk tickets. As offices around the world opened, we could not ask our workforce to sit as every connection had to go back through a central location.

We also had to be ready to scale. Some organizations are currently scrambling to load test their own VPN in the event that their entire workforce needs to work remotely during the COVID-19 outbreak. We could not let a single physical appliance constrain our ability to deliver 26M Internet properties to audiences around the world.

To run a network like Cloudflare, we needed to use Cloudflare’s network to stay fast and secure.

We built Cloudflare Access, part of Cloudflare for Teams, as an internal project several years ago to start replacing our VPN with a faster, safer, alternative that made internal applications, no matter where they live ,seamless for our users.

To address the scale challenge, we built Cloudflare Access to run on Workers, Cloudflare’s serverless platform. Each data center in the Cloudflare network becomes a comprehensive identity proxy node, giving us the scale to stay productive from any location – and to do it for our customers as well.

Over the last two years, we’ve continued to expand its feature set by prioritizing the use cases we had to address to remove our reliance on a VPN. We’re excited to help customers stay online and productive with the same tools and services we use to run Cloudflare.

How does Cloudflare Access work?

Cloudflare Access is one-half of Cloudflare for Teams, a security platform that runs on Cloudflare’s network and focuses on keeping users, devices, and data safe without compromising experience or  performance. We built Cloudflare Access to solve our own headaches with private networks as we grew from a team concentrated in a single office to a globally distributed organization.

How Cloudflare keeps employees productive from any location

Cloudflare Access replaces corporate VPNs with Cloudflare’s network. Instead of placing internal tools on a private network, teams deploy them in any environment, including hybrid or multi-cloud models, and secure them consistently with Cloudflare’s network.

Administrators build rules to decide who should be able to reach the tools protected by Access. In turn, when users need to connect to those tools, they are prompted to authenticate with their team’s identity provider. Cloudflare Access checks their login against the list of allowed users and, if permitted, allows the request to proceed.

Deploying Access does not require exposing new holes in corporate firewalls. Teams connect their resources through a secure outbound connection, Argo Tunnel, which runs in your infrastructure to connect the applications and machines to Cloudflare. That tunnel makes outbound-only calls to the Cloudflare network and organizations can replace complex firewall rules with just one: disable all inbound connections.

To defend against attackers addressing IPs directly, Argo Tunnel can help secure the interface and force outbound requests through Cloudflare Access. With Argo Tunnel, and firewall rules preventing inbound traffic, no request can reach those IPs without first hitting Cloudflare, where Access can evaluate the request for authentication.

Administrators then build rules to decide who should authenticate to and reach the tools protected by Access. Whether those resources are virtual machines powering business operations or internal web applications, like Jira or iManage, when a user needs to connect, they pass through Cloudflare first.

When users need to connect to the tools behind Access, they are prompted to authenticate with their team’s SSO and, if valid, instantly connected to the application without being slowed down. Internally managed apps suddenly feel like SaaS products, and the login experience is seamless and familiar.

Behind the scenes, every request made to those internal tools hits Cloudflare first where we enforce identity-based policies. Access evaluates and logs every request to those apps for identity, giving administrators more visibility and security than a traditional VPN.

Our team members SSO into the Atlassian suite with one-click

We rely on a set of productivity tools built by Atlassian, including Jira and Confluence. We secure them with Cloudflare Access.

In the past, when our team members wanted to reach those applications, they first logged into the VPN with a separate set of credentials unique to their VPN client. They navigated to one of the applications, and then broke out a second set of credentials, specific to the Atlassian suite, to reach Jira or Wiki.

All of this was clunky, reliant on the VPN, and not integrated with our SSO provider.

We decided to put the Atlassian suite behind Access and to build a plugin that could use the login from Access to SSO the end user into the application. Users login with their SSO provider and are instantly redirected into Jira or Wiki or Bitbucket, authorized without managing extra credentials.

We selected Atlassian because nearly every member of our global team uses the product each day. Saving the time to input a second set of credentials, daily, has real impact. Additionally, removing the extra step makes reaching these critical tools easier from mobile devices.

When we rolled this out at Cloudflare, team members had one fewer disruption in their day. We all became accustomed to it. We only received real feedback when we disabled it, briefly, to test a new release. And that response was loud. When we returned momentarily to the old world of multiple login flows, we started to appreciate just how convenient SSO is for a team. The lesson motivated us to make this available, quickly, to our customers.

You can read more about using our Atlassian plugin in your organization, check out the announcement here.

Our engineers can SSH to the resources they need

When we launched Cloudflare Access, we started with browser-based applications. We built a command-line tool to make CLI operations a bit easier, but SSH connections still held us back from killing the VPN altogether.

To solve that challenge, we released support for SSH connections through Cloudflare Access. The feature builds on top of our Argo Tunnel and Argo Smart Routing products.

Argo Smart Routing intelligently routes traffic around Cloudflare’s network, so that our engineers can connect to any data center in our fleet without suffering from Internet congestion. The Argo Tunnel product creates secure, outbound-only, connections from our data centers back to our network.

Team members can then use their SSH client to connect without any special wrappers or alternate commands. Our command-line tool, `cloudflared`, generates a single config file change and our engineers are ready to reach servers around the world.

We started by making our internal code repositories available in this flow. Users login with our SSO and can pull and submit new code without the friction of a private network. We then expanded the deployment to make it possible for our reliability engineering team to connect to the data centers that power Cloudflare’s network without a VPN.

You can read more about using our SSH workflow in your organization in the post here.

We can onboard users rapidly

Cloudflare continues to grow as we add new team members in locations around the world. Keeping a manual list of bookmarks for new users no longer scales.

With Cloudflare Access, we have the pieces that we need to remove that step in the onboarding flow. We released a feature, the Access App Launch, that gives our users a single location from which they can launch any application they should be able to reach with a single click.

For administrators, the App Launch does not require additional configuration for each app. The dashboard reads an organization’s Access policies and only presents apps to the end user that they already have permission to reach. Each team member has a personalized dashboard, out of the box, that they can use to navigate and find the tools they need. No onboarding sessions required.

How Cloudflare keeps employees productive from any location

You can read more about using our App Launch feature in your organization in the post here.

Our security team can add logging everywhere with one-click

When users leave the office, security teams can lose a real layer of a defense-in-depth strategy. Employees do not badge into a front desk when they work remotely.

Cloudflare Access addresses remote work blindspots by adding additional visibility into how applications are used. Access logs every authentication event and, if enabled, every user request made to a resource protected by the platform. Administrators can capture every request and attribute it to a user and IP address without any code changes. Cloudflare Access can help teams meet compliance and regulatory requirements for distributed users without any additional development time.

Our Security team uses this data to audit every request made to internal resources without interrupting any application owners.

You can read more about using our per-request logging in your organization in the post here.

How to get started

Your team can use all of the same features to stay online and secure from any location. To find out more about Cloudflare for Teams, visit teams.cloudflare.com.

If you’re looking to get started with Cloudflare Access today, it’s available on any Cloudflare plan. The first five seats are free. Follow the link here to get started.
Finally, need help in getting it up? A quick start guide is available here.

Seamless remote work with Cloudflare Access

Post Syndicated from Sam Rhea original https://blog.cloudflare.com/seamless-remote-work-with-cloudflare-access/

Seamless remote work with Cloudflare Access

The novel coronavirus is actively changing how organizations work in real-time. According to Fortune, the virus has led to the “world’s largest work-from-home experiment.” As the epidemic crosses borders, employees are staying home and putting new stress on how companies manage remote work.

This is only accelerating an existing trend, however. Remote work has gained real traction in the last decade and Gartner projects that it will only continue. However, teams which are moving to a distributed model tend to do so slowly. When those timelines are accelerated, IT and security administrators need to be able to help their workforce respond without disrupting their team members.

Cloudflare Access can help teams migrate to a model that makes it seamless for users to work from any location, or any device, without the need for lengthy migrations or onboarding sessions. Cloudflare Access can be deployed in less than one hour and bring SaaS-like convenience and speed to the self-hosted applications that previously lived behind a VPN.

Leaving the castle-and-moat

When users share a physical space, working on a private network is easy. Users do not need clunky VPN clients to connect to the resources they need. Team members physically sit close to the origin servers and code repositories that power their corporate apps.

Seamless remote work with Cloudflare Access

In this castle-and-moat model, every team member is assumed to be trusted simply by their presence inside of the walls of the office. They can silently attempt to connect to any resource without any default checks. Administrators must build complex network segmentation to avoid breaches and logging is mostly absent.

Seamless remote work with Cloudflare Access

This model has begun to fall apart for two reasons: the shift to cloud-hosted applications and the distribution of employees around the world.

The first trend, cloud-hosted applications, shifts resources outside of the castle-and-moat. Corporate apps no longer live in on-premise data centers but operate from centralized cloud providers. Those environments can sit hundreds or thousands of miles away from users, slowing down the connections to the applications hosted in those providers.

The second shift, users working outside of the office or from branch offices, introduces both a performance challenge in addition to a security concern. Organizations need to poke holes in their perimeter to allow users to connect back into their private network, before sending those users on to their target destination.

The spread of the coronavirus has accelerated the trend of users working away from home. Remote workers are putting new strain on the VPN appliances that sit in corporate headquarters, and that adds to the burden of IT teams attempting to manage a workplace shift that is happening much faster than planned.

Cloudflare Access

Cloudflare Access is one-half of Cloudflare for Teams, a security platform that runs on Cloudflare’s network and focuses on keeping users, devices, and data safe without compromising for performance. We built Cloudflare Access to solve our own headaches with private networks as we grew from a team concentrated in a single office to a globally distributed organization.

Cloudflare Access replaces corporate VPNs with Cloudflare’s network. Instead of placing internal tools on a private network, teams deploy them in any environment, including hybrid or multi-cloud models, and secure them consistently with Cloudflare’s network.

Administrators build rules to decide who should be able to reach the tools protected by Access. In turn, when users need to connect to those tools, they are prompted to authenticate with their team’s identity provider. Cloudflare Access checks their login against the list of allowed users and, if permitted, allows the request to proceed.

Seamless remote work with Cloudflare Access

Work from any device

The coronavirus is not only changing where employees work, but also the devices they use to do their work. Digitimes reports that the demand for tablets continues to grow as workers find alternatives to the desktops sitting in corporate offices, a trend they attribute to the rise in cases of coronavirus and increasing percentages of employees working outside of the office.

Tablets and other mobile devices introduce new challenges for teams. Users need to install and configure a VPN profile to connect, if they can connect at all.

Cloudflare Access offers an alternative that requires no user action or IT administration. End users can login and reach their corporate apps from any device, no client or agent required.

Rapid remote development

Working remotely can be difficult for users doing their job on browser-based applications. It becomes much more difficult for engineers and developers who need to do their work over RDP or SSH.

In the event that teams need to connect to the desktops back inside of the office, Access also supports RDP connections. Team members can reach desktops over Cloudflare’s global network, reducing the latency of traditional VPN-based RDP clients. Organizations do not need to deploy new credentials or run the risk of leaving remote desktops open to the Internet. Cloudflare Access integrates with a team’s identity provider to bring SSO login to remote desktops.

Cloudflare Access also includes support for native SSH workflows. With Access, developers and engineers can connect over SSH to the code repositories or build systems they need to stay productive. Users can connect remotely, from low-end devices, to powerful servers and machines hosted in cloud environments.

Seamless remote work with Cloudflare Access

Additionally, with the SSH feature in Cloudflare Access, organizations can replace the static SSH keys that live on user devices with short-lived certificates generated when a user logs in to Okta, AzureAD, or any other supported identity provider. If team members working from home are using personal devices, organizations can prevent those devices from ever storing long-lived keys that can reach production systems or code repositories.

One-click logging and compliance

When users leave the office, security teams can lose a real layer of a defense-in-depth strategy. Employees do not badge into a front desk when they work remotely.

Cloudflare Access addresses remote work blindspots by adding additional visibility into how applications are used. Access logs every authentication event and, if enabled, every user request made to a resource protected by the platform. Administrators can capture every request and attribute it to a user and IP address without any code changes. Cloudflare Access can help teams meet compliance and regulatory requirements for distributed users without any additional development time.

Onboard users without onboarding sessions

When IT departments change how users do their work, even to faster and safer models, those shifts can still require teams to invest time in training employees. Discoverability becomes a real problem. If users cannot find the applications they need, teams lose the benefit of faster connections and maintenance overhead.

Cloudflare Access includes an application launchpad , available to every user with additional configuration. With the Access App Launch, administrators can also skip sending custom emails or lists of links to new contractors and replace them with a single URL. When external users login with LinkedIn, GitHub, or any other provider, the Access App Launch will display only the applications they can reach. In a single view, users can find and launch the tools that they need.

Whether those users are employees or contractors and partners, every team member can quickly find the tools they need to avoid losing a step as they shift from working on a private network to a model built on Cloudflare’s global network.

Seamless remote work with Cloudflare Access

How to get started

It’s really very simple. To find out more about Cloudflare for Teams, visit teams.cloudflare.com.

If you’re looking to get started with Cloudflare Access today, it’s available on any Cloudflare plan. The first five seats are free. Follow the link here to get started.

Finally, need help in getting it up? A quick start guide is available here.