DEV Community: Malavika Rajesh

Strengthening Remote Work Security with CASB and DNS Filtering

Malavika Rajesh — Thu, 13 Aug 2026 08:55:19 +0000

Remote work has changed how organizations manage security. Employees now access cloud applications, websites, and company resources from different locations and devices. This makes it important for organizations to have security controls that provide visibility and help manage access across distributed environments.

One useful approach is combining Zero Trust access with additional layers of security such as Cloud Access Security Broker (CASB) capabilities and DNS filtering.

Why CASB Matters

Cloud applications are now an important part of everyday business operations. Employees may use multiple cloud services to communicate, store files, collaborate, and manage projects. This can create security challenges when organizations do not have enough visibility into cloud usage.

A CASB capability can help organizations gain better visibility and control over cloud application activity. It provides an additional security layer between users and cloud services, helping organizations manage cloud access while supporting their broader security policies.

For distributed teams, this type of visibility can make it easier for administrators to understand how cloud resources are being accessed and identify areas that may require additional security controls.

The Role of DNS Filtering

DNS is another important part of internet access. When users visit a website or connect to an online service, DNS helps translate domain names into network addresses. Because DNS requests occur frequently, controlling DNS traffic can provide another opportunity to improve security.

DNS Filtering can help organizations control access to domains according to defined security policies. This can reduce exposure to unwanted or potentially risky destinations and give administrators greater control over internet access.

A Layered Security Approach

CASB and DNS filtering work well as complementary security controls. CASB focuses on cloud application visibility and access, while DNS filtering provides control at the domain level. When combined with Zero Trust principles, identity-based policies, and device security, these capabilities can contribute to a stronger remote-work security strategy.

Modern organizations need more than a traditional VPN to protect distributed teams. A layered approach helps security teams manage access, improve visibility, and apply consistent policies across users and devices.

To explore more QuickZTNA capabilities, visit the QuickZTNA platform and QuickZTNA Features.

What Modern Remote Access Should Consider Beyond the VPN

Malavika Rajesh — Wed, 12 Aug 2026 05:47:12 +0000

Remote access is no longer just a question of connecting a laptop to a private network. As organizations adopt distributed teams, cloud infrastructure, and device-based security controls, the underlying architecture of remote connectivity has become more important.

A traditional VPN can still provide encrypted communication, but it does not automatically answer questions such as: Who should access a particular resource? Is the connecting device trustworthy? How should access policies change over time? And what happens when the organization needs to meet newer security or compliance expectations?

One area receiving increasing attention is post-quantum security. Organizations evaluating VPN or ZTNA solutions should look beyond general claims of “quantum readiness.” Questions around the cryptographic algorithms being used, whether post-quantum mechanisms are actually deployed, and how keys are managed can provide a much clearer picture. A practical checklist for evaluating these claims is discussed in Post-Quantum VPN: 6 Questions to Ask Your Current Vendor.

Another architectural decision involves the coordination layer behind encrypted device-to-device networks. WireGuard provides the encrypted data plane, but managing device discovery, authentication, policies, and connectivity across multiple machines can become complicated as a network grows. Teams may choose between operating their own coordination infrastructure or using a managed service. The trade-offs include operational effort, control, maintenance responsibilities, and cost. The comparison in Self-Hosting Headscale vs a Managed Coordination Server explores these differences.

Compliance is another factor that increasingly influences remote-access architecture. For organizations affected by NIS2, security teams need to consider how remote access fits into broader requirements for risk management, access control, authentication, monitoring, and security measures. Rather than treating compliance as a separate layer added after deployment, these requirements can influence the architecture from the beginning. A practical breakdown is available in NIS2 Directive Remote Access Requirements: A Builder's Checklist.

The larger lesson is that remote access should be evaluated as an architecture, rather than simply as a VPN product. Encryption is important, but identity, device posture, authorization, coordination, monitoring, and regulatory requirements all affect how securely employees and systems can connect.

For organizations reviewing their current setup, a useful starting point is to document how users authenticate, how devices are verified, which resources they can reach, how access decisions are enforced, and what evidence is retained for security reviews.

That approach makes it easier to identify gaps before they become operational or compliance problems.

Managing Remote Access, Observability, and Billing in a Modern Security Platform

Malavika Rajesh — Tue, 11 Aug 2026 09:29:23 +0000

Managing Remote Access, Observability, and Billing in a Modern Security Platform

With increasing trends of distributed working, managing security infrastructure becomes much more complicated than just securing an office network. The modern workplace has employees connecting to it from various places, cloud workloads, remote servers, and internal applications. In addition to that, administrators need to keep control of their infrastructure and be aware of all the resources they use.

It is supposed that a modern security platform will simplify these administrative activities, rather than complicate them even further.
**
Remote Access Needs to Be Controlled
**
One of the areas which require attention of any organization dealing with distributed team is remote access. It is often the case when employees and administrators need to gain access to their internal systems, not making these systems directly available on the Internet.

There are many ways of implementing remote access besides traditional username and password. For example, access can be assessed based on identity, device, permissions, and other contexts, thus enabling only necessary access to the resource and minimizing network exposure.

For administrators interested in remote access in Zero Trust architecture, there is an additional remote access guide available in QuickZTNA project.

Visibility Gained Through Observability

Security controls are only helpful when the administrator knows what is going on within the environment. Without enough visibility, any anomalies, configuration issues, or access problems could be challenging to detect.

The observability process could allow the team to gather important security and infrastructure information from one centralized place. Logs, events, connection details, and other operational information could be valuable during problem solving and investigations of any anomalies.

Without having to make any assumptions, the administrator could get information about how the system is accessed and which area should be taken into consideration.

For further information on observability, see the QuickZTNA observability documentation.
**
Billing and Resource Usage Transparency**

Another operational aspect that is often neglected with security solutions is billing and resource usage. The team must know the account structure and usage in case they add more users, devices, or capabilities.

Having transparency regarding the billing information will help the organization to budget, track usage, and decide when scaling the security infrastructure is necessary. It will also help the administrator to differentiate essential capabilities from unnecessary ones.
The QuickZTNA billing guide can help administrators understand the billing-related aspects of managing the platform.

Bringing Administration into the Mix

Remote access, observability, and billing may seem like different administrative activities, but they all share one key thing – visibility and control.

A growing company needs to know who accesses their resources, what is going on in their environment, and how the security infrastructure is used. Aligning those activities within a proper administrative process can help make security operations easier as the company grows.

Zero Trust security is not just about implementing more secure authentication or limited network access. Zero Trust is also about building an environment that allows admins to make the right decisions.

By aligning remote access, observability, and account management within controlled environments, companies can build their security environment in such a way that it will be easier to operate, while still allowing proper access controls for remote teams.

Stop Exposing SSH to the Internet: A Better Way to Access Private Servers

Malavika Rajesh — Tue, 04 Aug 2026 09:20:01 +0000

SSH is one of those tools that are used automatically by the developers.

Want to see what's going on with the server?

ssh user@server

Easy.

However, public SSH access usually requires exposing port 22 to the web, setting up firewalls, limiting IP addresses, or adding a bastion host before the internal network.

It will work, but as you add more infrastructure, it will become harder to manage your remote access.

There is an alternative, however – to keep the servers private and limit their access with a Zero Trust network.

Why Public SSH Access May Be an Issue

Publicly accessible SSH server is always exposed to the internet.

Although authentication is done properly, there is always a need to think about firewalls, credentials, authorized users, IP address restrictions, and monitoring.

One of the solutions to reduce the exposure is to allow SSH access from a specific set of IP addresses.

However, it will not be convenient for remote developers.
Bastion Host could also be considered another popular choice:

Developer
↓
Bastion Host
↓
Private Server

Here we decrease exposure of the internal servers, however, the bastion becomes another infrastructure component that needs to be protected and maintained.

But What If There Was No Need for SSH on the Server from the Outside?

Instead of exposing SSH externally, let us picture the developer and the server communicating via a private encrypted channel.

Developer Laptop
↓
Private Encrypted Channel
↓
Production Server

We have no need to expose SSH while the server remains behind its firewall, and devices access the server via a private encrypted channel.

It is at this point when solutions like Zero Trust Network Access start getting interesting.

QuickZTNA works by connecting devices and infrastructure via WireGuard-based private mesh while applying Zero Trust security controls to access.

And the whole point is not to provide yet another tunnel but to control what and who accesses what.
**
Being Connected Does Not Necessarily Mean Having Access to Everything**

If five developers are connected to the company's internal infrastructure.

It does not necessarily mean that all of them are automatically granted SSH access to every single server.

First developer requires access to the staging environment.

Second developer requires access to the production environment.

Contractor requires a dev environment only.

Zero Trust approach may provide more accurate permissions.

For instance:

Developer + Approved Device + SSH + Production = Allow

Contractor + SSH + Production = Deny

Access policies implemented by QuickZTNA Zero Trust follow the principle of least privileges: users are granted the access they really need instead of the access to the entire network.

*What About the Setup?
*
Security upgrades are quite useless if their implementation requires one person full-time job.
For small teams of engineers, maintaining such things as VPN gateways, bastion hosts, firewall configurations, and networking could lead to unnecessary complexity.

One way to simplify is by connecting authorized devices directly to the managed private network.

The QuickZTNA Quickstart demonstrates how the administrator can generate an authentication key, install the client and connect the device without manually exchanging WireGuard keys or configuring inbound firewall ports.

It would be especially helpful for small DevOps teams that need to have access to their private infrastructure without maintaining any additional gateway infrastructure.
**
Conclusion**

SSH isn’t the problem itself.

The real question here is how to make SSH reachable.

Ports, IP allowlists, and bastions could help to solve certain aspects of remote access problems.

Zero Trust networking provides an alternative approach: keep your infrastructure private, identify who and what is asking for access, and provide access to required resources only.

From the point of view of developers, this changes the question:

“How do I expose this server safely?”

“Do I really need to expose this server?”