devopsy.kinsta.cloud

Category: DevOps in the Cloud

Atlassian Bitbucket CI/CD Cloud Service Aims for the Enterprise

Atlassian today outlined its strategy to increase the appeal of the Bitbucket continuous integration/continuous delivery (CI/CD) cloud service among enterprise IT organizations. Atlassian said it plans to focus on four core pillars: Performance, management, extensibility and security and compliance, starting with an update scheduled for the third quarter.

Dan Tao, head of engineering for Bitbucket Cloud and Compass at Atlassian, said the overall goal is to make it simpler to use the Bitbucket Cloud service running on the Amazon Web Services (AWS) cloud at scale as organizations increase the rate at which they build and deploy software.

Atlassian is still supporting the Bitbucket Server and Data Center editions of the platform, but it’s apparent more organizations are shifting software development to the cloud, he noted. Atlassian is now moving to not only simplify migrations to the cloud by, for example, providing a Bitbucket Cloud Migration Assistant tool, but it is also moving to ensure applications can be developed at scale.

Achieving that goal includes making use of a more advanced diff algorithm that is four times faster in larger DevOps environments, he added.

Other planned enhancements include the ability to execute CI/CD workflows via Bitbucket pipelines, the ability to reuse multi-step pipelines across repositories, tighter administration integration with other Atlassian applications, the ability to encrypt data at rest and integration with the Snyk tool for discovering vulnerabilities in software to improve security.

Finally, the Bitbucket Cloud service will also soon support Bitbucket Mesh, a distributed storage capability that is already employed in Bitbucket Data Center.

Overall, Atlassian sees the migration to the cloud as a means to not only make DevOps workflows more accessible to a wider range of organizations, but also give organizations that have already invested in DevOps the opportunity to streamline those processes, said Tao.

Many DevOps teams today maintain complex platforms with custom integrations that they need to maintain and support. Atlassian provides DevOps teams the option to either employ an integrated platform or use connectors it has created as part of the Atlassian Open DevOps framework to make it simpler for teams to use whatever mix of tools they prefer, he added. In either case, the total cost of maintaining a DevOps environment can be significantly reduced, said Tao.

It’s not clear to what degree organizations that have already invested in DevOps are considering replacing their existing CI/CD platforms. However, as the pressure to accelerate the rate at which software is built and deployed steadily increases, the pressure to further automate DevOps workflows also builds. At the same time, DevOps teams are now being asked to integrate security gateways that require additional custom integrations within legacy platforms that they would need to support alongside existing integrations.

At the very least, more organizations than ever are weighing their DevOps options. The issue, of course, is that the total cost of switching out DevOps platforms is not inconsequential given the current dependency on existing workflows.

July 19, 2022
What SASE Means for DevOps Teams
You have probably heard the acronym secure access service edge (SASE), and it’s hard to ignore its impact on the technology industry. SASE is a cool new way to implement networking in hybrid environments, and the most important thing about it is that it bakes security into the network fabric. In plain English—when you plug in, you are secure by default.

SASE will have a special impact on two fields near and dear to the hearts of DevOps teams:
1. Cloud security—SASE has the potential to transform how we practice security in the multi-cloud, and unify it with security in the central data center.
2. DevSecOps adoption—SASE can make DevSecOps easier to adopt and might become essential infrastructure for globally distributed DevSecOps teams.
Let’s understand the anatomy of the SASE beast, and understand how it will affect DevOps in the years to come.

What Is SASE?

SASE is a cloud service that extends networking and security capabilities to support hybrid organizations’ dynamic, secure access needs.

SASE combines WAN capabilities with network and security functions, such as firewall-as-a-service (FWaaS), zero-trust network access (ZTNA), secure web gateway (SWG) and more.

A SASE platform bundles multiple security capabilities, including SD-WAN and services like SWG, CASB, ZTNA, FaaS and SaaS. This multi-region, multitenant architecture supports a distributed and remote workforce. SASE uses inspection engines located at points of presence (PoPs) near the endpoints rather than in the data center. SASE clients send traffic to the nearest PoP.

The core characteristics of a SASE architecture are:
- Global SD-WAN—A private SD-WAN backbone helps reduce latency by avoiding the public internet.
- Distributed architecture—SASE inspects traffic and enforces policies at the edge using multiple inspection engines.
- Cloud infrastructure—SASE delivers services via the cloud, so tenants don’t have to maintain hardware and other infrastructure resources. This approach is scalable and cost-effective.
- Identity-based access—Access controls use identity markers like the user’s location and device.
SASE Adoption Drivers: Why Do Organizations Want It?

Cost Reduction

Using physical and virtual appliances from multiple vendors is highly cumbersome and costly. SASE enables organizations to replace this disparate model with a single, cloud-native solution. Organizations can use SASE to deliver more technologies and services via one provider instead of several. As a result, it eliminates the cost of miscellaneous network appliances and optimizes cloud costs, by reducing the resources and bandwidth needed to operate a cloud environment.

Edge-to-Edge Security

SD-WAN is an integral component of SASE, providing features such as an active-active failover and WAN optimization that improve performance and increase network resilience. SASE solutions are based on the concept of security automation, with a fully managed network security stack that typically includes SWGs, next-generation firewalls (NGFW), next-generation network architecture and intrusion prevention systems (IPS). This model helps protect all edges, achieving better network visibility.

Data Protection

SASE provides a holistic data protection experience that automates multiple DLP processes, including data discovery and data classification of storage locations, data usage and data in transit. It employs various security measures, such as user and device authentication, to enable control over access to data and resources at all times. Additionally, SASE DLP seamlessly rolls out protection policies across the entire network.

Impact: How SASE Will Transform the Cloud Security Stack

The emergence of services like PaaS, SaaS and IaaS has encouraged organizations to allow remote work. The cloud supports distributed workforces and streamlines business processes, but it also exposes companies to network-based threats. Many organizations store sensitive data with third parties accessed online.

The cloud security stack can easily become siloed, with team members unsure of their responsibilities and overlooking critical processes. A siloed stack is more labor-intensive and harder to track because the security team uses multiple security systems. It can also create alert fatigue, making it hard to identify threats.

While employees mostly work in the cloud, security efforts often focus on the data center. SASE shifts the focus to the cloud while ensuring seamless integration between security services.

With SASE, a single provider delivers the entire security stack, ensuring it functions as a unit. For instance, an SWG uses threat intelligence data to block suspicious traffic, sending unidentified files to a sandbox for testing. The security team can manage the entire stack from one intuitive interface.

Most activities occur at the edge—SASE secures the edge using an identity-driven approach. It is also cloud-native, ensuring a seamless experience.

Impact: How SASE Will Promote DevSecOps Adoption

SASE provides the following advantages for adopting DevSecOps.

Facilitating Collaboration

SASE helps reduce the challenges involved in cross-team collaboration. Essentially, SASE combines network security with WAN optimization. Modern DevOps teams are physically separate but must work together, requiring reliable and secure connections between team members.

The DevOps approach emphasizes time-to-market, so DevOps teams look for ways to accelerate the CI/CD cycle and push releases faster. An important part of the process is reducing the DevOps team’s reliance on the network and security teams. SASE solutions help optimize performance and enhance security, so the DevOps team doesn’t have to wait for the infrastructure team to configure resources. SASE gives DevOps teams the necessary control and operational cadence without compromising security or performance.

Enhanced Networking

SASE can improve the overall network performance by providing integrated failover and load balancing capabilities. DevOps teams must have reliable connectivity and cannot tolerate disruptions when deploying new software or fixing bugs. Fast, reliable application performance is key to the DevOps workflow.

The SASE architecture improves the networking, ensuring the organization’s edge devices, cloud resources, data center and remote users remain connected. The DevOps team doesn’t have to handle the infrastructure because it is self-healing, fully optimized, and secure. The solution automatically switches to another path if a line fails or a path becomes congested.

Security By Default

SASE protects DevOps projects with built-in security features. When implemented properly, it integrates many security technologies into the network stack. The DevOps team doesn’t have to worry about attackers intercepting sensitive information. Every security service shares the same, unified context to increase visibility and fill gaps that are often present in traditional security architectures. SASE mitigates the vulnerabilities exploited by attackers using NGFW, SWG, IPS, MDR and antivirus services in a single architecture.

SASE can secure internal applications and their interactions, reducing the burden on the DevSecOps team. Applications running on a SASE-based SD-WAN benefit from the added protection of zero-trust network access (ZTNA) and software-defined perimeter (SDP). These technologies help ensure that all interactions between applications and endpoints are secure.

Proprietary apps are often too sensitive to expose to the public Internet. SASE secures these applications by obfuscating traffic, securing all entry points with NGFW, and restricting access with zero-trust network architecture. It constantly inspects all internal application traffic for cybersecurity threats.

Conclusion

In this article, I explained the basics of SASE, which packages multiple networking and security solutions into one managed service.

SASE is giving organizations a new level of flexibility and agility with regard to their core infrastructure and is introducing the concept of security-by-design. Instead of fighting hard to “secure all the things,” we are moving nearer to a world where the “grid” our organization operates on is secure by default. This won’t make DevSecOps any less important. But it will allow us to build our applications and services within a secure, controlled hybrid environment.
July 19, 2022
Red Hat CEO: Out | Blind Users: Revolt | ARM: Google Joins Party

Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

This week: Matt Hicks is the new Red Hat CEO, visual accessibility is in focus, and Google Cloud rolls out ARM instances. (more…)

July 14, 2022
Resolving CI/CD Permissions Issues to Address Delivery Needs

Security concerns and DevOps process issues can stall CI/CD operations. DevOps teams are familiar with the frustrations plaguing their pipelines, whether regulatory or process-based. Operational hurdles are all too common in DevOps pipelines, leading to miscommunication between team members and the broader organization. One of the leading operational issues DevOps teams encounter is permission issues. Permission issues are a seemingly small yet significant roadblock to smooth CI/CD pipelines. Fail to address them and the result is a lack of cohesion between development and organizational objectives.

Here’s how to streamline these processes, boost security integration within the broader CI/CD framework, and maintain robust security postures.

Review Pipeline Tools for Permissions and Access

The DevOps life cycle often contains multiple tools, all with different access needs and permissions. As such, this situation is a security nightmare. Jeremy Hess, head of DevRel at secrets management platform Akeyless, called this a “secrets sprawl.”

“The combination of proliferation and decentralization of secrets creates an operational burden, if not a nightmare,” he said. “For organizations that operate in both a cloud-native environment and classic IT infrastructure, a duplication issue is created due to having their own secrets managed with different tools and cloud-native solutions.”

There is also the risk of these tools exposing user credentials and permissions to malicious actors. For instance, configuration tools like Jenkins use plugins to determine access and artifact deployment. Because these tools communicate with other pipeline tools, credential details can often be present in configuration details.

Developer passwords are not visible on the frontend but could accessible from the system backend. Any user with ‘configure’ permissions could request any credential and then inject them into agents. The result is that AWS keys, Git credentials and/or passwords are at risk.

To mitigate this issue, the first step involves deleting hard-coded secrets from CI/CD tool files. Distributing secrets between multiple tool configuration files also reduces the possibility of attack while easing developer and engineer access. Password managers are also a good choice, but validate them for security before implementing a solution.

Practice Least-Privilege Access

Access and permission issues often create a lot of frustration among DevOps teams as they are forced to assign blanket access to the majority of users, regardless of members’ roles or job functions. While this situation encourages rapid development, it also creates massive security issues.

Balancing security with CI/CD needs is tough to get right. That’s where the principle of least privilege comes in. Team members receive access to secrets on a need-to-know basis. Note that this principle applies to everything from apps to systems and connected devices.

While most teams put this principle into practice, they make the mistake of leaving their process intact. The lack of access audits creates DevOps frustration, not the level of access. CISOs should regularly involve DevOps teams when reviewing access to mitigate issues quickly.

For instance, embedding a security role within every delivery team will mitigate access-related risks quickly. The security team member will have insights into risk-based access needs and can quickly approve or reject requests.

Creating an access management repository will also remove any confusion related to role-based access. In addition, record time-based and task-based access permissions in the repository. The result is every DevOps team member understands their access paths before projects get started. It allows them time to offer feedback and request one-off access to sensitive secrets.

Review segmentation rules within your systems when assigning role-based access. Often, these rules will have to change depending on delivery timelines. Involving all stakeholders in these discussions is good practice and prevents frustration down the road.

Implementing OTPs and other authentication factors is also a good idea when validating user access to secrets.

Review OSS Projects

Open source software (OSS) projects are essential to industry growth but might pose security risks if access is mismanaged. Zan Markan, developer advocate at CI platform CircleCI, summarizes the problem aptly.

“Often, the company that initiated and that owns a popular OSS project continues to employ the core contributors,” he said. “They will probably be joined by other regular contributors and maintainers that are not part of that company. And then there is everyone else—anyone who occasionally might contribute a fix or a feature.”

As user access grows, security concerns grow exponentially. Enforcing rigid user-based access is unrealistic and detrimental to an OSS project. However, CISOs or other security-focused managers must review whether sensitive secrets are being passed during builds for pull requests. Monitoring permissions—and who can place requests and roles that review them—will ensure a good level of security.

Establishing machine identity is also critical, given the degree of non-human access pipelines face. Authentication can be based on verifying whether client runtime container attributes match the characteristics of the valid container. Once authenticated, role-based access can take over, limiting access to secrets.

It’s also a good policy to destroy containers and VMs after they’ve been used.

Streamlining DevOps Operations is a Top Security Priority

DevOps is critical to every organization’s success. Access and permission-related issues are common occurrences, but are easily avoided. Reviewing access and establishing a balance between delivery and operational needs is essential to maintaining a competitive edge.

July 14, 2022
ERP Modernization: How Devs Can Help Companies Innovate

In this post-pandemic world, large enterprises are looking to streamline and improve business processes within a storm of marketplace constraints. Companies in asset-heavy industries such as oil and gas, energy, retail, or distribution and logistics have especially been working to reconfigure their supply chain processes to better manage inventory and operations. The focus in the market has shifted from supply chain optimization to supply chain resiliency, creating efficiencies that will help them best survive current delays and rising costs.

Breaking Barriers and Addressing the Talent Shortage

The question is not simply whether companies need to modernize their business applications to increase efficiency and lower costs, but how to accomplish a necessary modernization in the midst of barriers like rising costs, supply chain disruptions and a severe shortage of developer talent. Developers and DevOps teams need to find ways to do more with less.

The reimagining of business processes is an excellent strategy to reduce overhead and allow companies to become nimbler and more efficient, consequently helping them preserve or improve marketshare. Many large enterprises work in environments that use enterprise resource planning (ERP) software; systems that, over the years, have been subject to ongoing upgrades, patches and redesigns by developers and IT managers. This creates technical debt, which makes it difficult for many of these large-scale companies to migrate their business applications to cloud-based systems.

Many of these ERP-based companies are facing pressure to update to more modern, cloud-based versions of their ERP platforms. But they must run a gauntlet to modernize their legacy applications. In a sense, companies that maintain these complex ERP-based systems find the environments are like “golden handcuffs.” They have become so complicated over time that they restrain IT departments’ innovation efforts, hindering their ability to create supply chain resiliency when it is most needed.

To make matters more difficult, the current market is facing a global shortage of human resources required to get the job of digital transformation and application modernization done, including skilled ERP developers—especially those skilled in more antiquated languages like ABAP. Incoming developer talent is often trained in more contemporary languages like Java, Steampunk and Python. These graduates have their pick of opportunities and gravitate to companies that already work in these newer programming environments.

ERP migrations can be hampered by complex, customized systems developed by high-priced, silo-skilled programmers. Many enterprise leaders have a great desire to break out of these restrictions and modernize legacy applications with greater speed and at lower cost, and they need to do so with minimal downtime and disruption.

Leverage Low-Code Solutions to Modernize

In a 2022 report on application development strategies, industry analyst Deepa Salem interviewed enterprise companies that used sophisticated SAP-based ERP solutions about their approach to software modernization strategies. More than 80% of respondents said they planned to upgrade their business applications in conjunction with a major migration of their ERP software platform to the latest, cloud-based version.

This tactic of implementing a new applications strategy in coordination with a major refresh is not surprising and presents an opportunity for developers to help these companies “clean house,” reducing the technical debt of their legacy environments at this well-timed juncture.

As an analogy, think about how people typically move to a new residence. Homeowners sift through their accumulated possessions and identify what’s no longer needed. They pack what is still valuable and essential. A low-code application process can help clean up existing ERP environments prior to migration, reducing complexity and long-accumulated technical debt while leveraging the system’s unique business intelligence. The tribal knowledge inherent in any legacy system is critical to retaining market differentiation.

With so much at stake, IT departments and developers should give serious consideration to using pre-built, customizable business applications, efficiently and rapidly created through a low-code development process. Deployment-ready solutions can help developers move forward with modernization projects that have been hampered or shelved due to a lack of talent to implement those jobs. They can accomplish more with less.

With the right approach, ERP-based environments can be reconfigured to quickly establish more agile, streamlined and cost-effective business applications. Developers have a unique opportunity to help enterprises keep what sets them apart from the competition and surrender what no longer serves them. In this climate, this is not a nicety for enterprise customers. It’s about resilience—and even survival.

July 8, 2022
Dev Job Phisher Steals $540M | Patch OpenSSL NOW | Systemd Dev Joins Microsoft

Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

This week: Spear-phishing causes $540 million loss, a high severity bug in OpenSSL might be “worse than Heartbleed,” and Lennart Poettering is now working for Microsoft. (more…)

July 7, 2022
Rust in Linux 5.20 | Deepfake Hiring Fraud | IBM WFH ‘New Normal’

Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

This week: Linus says next release will support Rust, FBI warns scammers are getting hired in deepfake interviews, and 80% of IBM staff stay at home. (more…)

June 30, 2022
Moving From Lift-and-Shift to Cloud-Native

Analyst firm Forrester recently predicted that 2022 “will see big organizations move decisively away from lift-and-shift approaches to the cloud, embracing cloud-native technologies instead.”

According to Gartner, more than 85% of enterprises “will embrace a cloud-first principle by 2025 and will not be able to fully execute on their digital strategies without the use of cloud-native architectures and technologies.”

As the Gartner analysts put it, “cloud-native platforms improve on the traditional lift-and-shift approach to cloud, which fails to take advantage of the benefits of cloud and adds complexity to maintenance.”

What’s happening here? Is lift-and-shift–long seen as a relatively quick and inexpensive way to migrate existing workloads to the cloud–really going the way of the dinosaur? Has the cloud-native future really arrived?

I think the true answer is somewhere in the middle right now. Yes, many companies have adopted a cloud-first strategy, turning to the cloud as an assumed starting point for most or all of their application needs. But many others still have a mix of on-premises infrastructure and public cloud infrastructure with opportunistic lifting-and-shifting from one to the other rather than a holistic cloud-native model.

Lift-and-shift has been and remains a perfectly natural and effective step in many organizations’ cloud journeys. All you do is redirect a copy of an application from an on-premises data center to the cloud–no need to redesign the app’s architecture or code.

This method offers a fast and efficient way to leverage the cloud’s benefits: The ability to focus IT dollars on operational (rent) rather than capital (own) expense and take advantage of the extensible computing power, storage and other services in the cloud.

In contrast with lifting and shifting, a cloud-native approach takes longer and is more labor-intensive because it takes many moving parts to redesign the entire app ecosystem. The payoff comes later with lower total cost of ownership and more flexible, responsive infrastructure.

If many companies are still lifting-and-shifting, why are the analysts so bullish that it is on its way out? Because lift-and-shift isn’t as simple and inexpensive as it looks. It essentially defers the eventual re-engineering to cloud-native and yet still requires an investment in capacity, people, money and time.

First, despite lift-and-shift’s promise as an easy way to migrate existing applications to the cloud, it is common for organizations, no matter how much they plan, to hit some technical roadblocks in the execution. An app that worked a certain way in the legacy environment might not work exactly the same way in the cloud, and these details must be worked out.

Second, companies are often caught off guard by cloud “sticker shock”–the unpleasant billing surprises that occur when workloads exceed the capacity agreed on with the cloud provider.

Third, while lift-and-shift is a way to advance on the cloud path, it’s not the ultimate destination.

The Cloud Native Computing Foundation defines cloud-native technologies as empowering organizations “to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.”

That’s a much bigger vision than the intermediary steps that lift-and-shift entails.

What should companies still engaged in a lot of lifting-and-shifting be doing to prepare for their cloud-first future?

1. Containerize like crazy. Virtualization was a game-changer because it allowed companies to abstract away hardware and run multiple virtual machines (VMs) on a single piece of hardware. This allowed a move in best practices toward a VM-per-function. Process containers, made famous by Docker and Kubernetes, are a logical extension of this concept: Stripping out redundant pieces of an operating system so that each logical unit contains only what is needed for the function it is designed to achieve. That, combined with a more deliberate approach to separating application and data, is the secret sauce of a cloud-native enterprise. Container adoption has been growing rapidly in enterprises–Gartner has predicted that containers will be the “default choice for 75% of new customer enterprise applications” by 2024. This trend bodes well for the move away from lift-and-shift to cloud-native and brings organizations closer to “write once, deploy anywhere” as each of the major cloud platforms and many on-premises tools provide mechanisms to run containers as first-class citizens.

2. Consider the skills equation and where you want to focus your efforts. Every company embarking on a cloud-native strategy needs to carefully examine to what extent they’ll need architects and other skilled pros to carry it out. They need to think about what makes sense in terms of hiring people in-house, outsourcing to third-party experts and leveraging public cloud offerings such as serverless computing that reduce labor requirements. It may be more sensible, for example, to focus on migrating application development to containers but rely on public cloud container platforms, low-ops Kubernetes or managed data center Kubernetes services rather than trying to build that competence in parallel.

3. Rely heavily on automation. One of the advantages of containers encapsulating everything they need is that it makes it easier to build, test and deploy them as part of a CI/CD pipeline. Given they are also normally easier to scale horizontally, it is possible to automate how the application will scale to respond to external factors. Taking a model-driven approach to cloud-native applications can help DevOps teams and developers understand the conceptual pieces and relationships between complex software deployments while automating some of the details and life cycle management. Monitoring microservices brings its own set of challenges, so it is important to ensure that the observability tools you are using were designed to be effective with cloud-native applications. Cloud-native can bring great scalability benefits, but only with sufficient automation to limit friction in the cloud-first journey.

4. Have a strong update strategy. Moving to containers distributes your software provenance and update problem across a much greater number of pieces; containers are not normally updated but instead are replaced with an updated version. This changes your traditional update approach. It is more important than ever that the pieces you are putting into those containers at build-time have a good software provenance and update story.

5. Think holistically. Ruthlessly evaluate what apps can be cloud-native and which should remain in the data center and then consider the true benefits of hybrid cloud. Some organizations get caught up in thinking they need to move everything to the cloud wholesale. Maybe cloud-native isn’t right for everything.

The industry-wide transition from lift-and-shift to cloud-native is accelerating. By keeping these five points in mind, companies can feel confident they’re moving forward, too.

June 30, 2022
Common RDS Misconfigurations DevSecOps Teams Should Know

Relational databases have become the option of choice for organizations wishing to streamline and scale the use, storage and retrieval of data. Many organizations choose AWS Relational Database Service (RDS) to forego the resource-intensive tasks related to database administration including management and continuous oversight. RDS is a fully managed service that simplifies and automates these processes, making it easy to set up, operate and manage relational databases in the cloud—including MySQL, PostgreSQL, MariaDB or Aurora—and their various time-consuming activities. Reducing costs and automating processes makes significant business sense and allows organizations to focus on performance, scalability and cost-effectiveness as data grows.

That said, AWS is not the owner or the party responsible for securing your data—this duty remains in the hands of the organization. As the cloud provider, AWS does offer an impressive suite of security measures for protecting the infrastructure that runs its cloud services, including access controls, database snapshots and encryption. Their policies, however, clearly state that safeguarding data is within the responsibility of the organization and, as the moderator of your environment, you will be accountable for what occurs within it.

The following are the six most common RDS misconfigurations related to security and compliance that DevSecOps teams should be aware of to secure their data stores and organizational assets.

Broken Geo-Trust (aka Data Sovereignty): RDS provides the convenient option to distribute data across various AWS regions. There are various benefits to this data migration including minimizing latency, disaster recovery capabilities and scaling operations. However, the security and governance risks of cross-geo replication may significantly outweigh these benefits. A common misconfiguration includes migrating replicas or storing backups and snapshots in another location. When sensitive data travels and is stored in another geographic location, the organization may be at risk of violating international compliance requirements such as Schrems II (for EU-to-U.S. data transfer). Additionally, data traveling to various locations may not be visible to security teams or managed by DevOps teams—without a continuously updated inventory, data will spread unobstructed and ungoverned.

The screenshot below displays a copy-snapshot operation of a U.S.-based RDS datastore to an EU region.

Inadequate Retention Periods: AWS allows organizations to retain database instances for a specific period of time as configured by the user. A common misconfiguration of this feature is the existence of unmonitored standalone snapshots, short-lived backups and a failure to permanently delete records. Organizations that retain records for a long period of time may be in breach of their GDPR obligations, whereas short-lived backups may jeopardize the organization’s ability to recover critical data in case of data loss or a ransomware attack. Clear guidelines and open communication between DevOps teams and compliance leads is the first step toward a healthy environment.

The screenshot below presents a recommended and comprehensive backup retention period configuration from an RDS datastore creation process.

Exposed Resources (Network Access): Publicly accessible database ports and RDS instances are a lucrative configuration loophole for malicious actors. Common misconfigurations may cause RDS database snapshots to be publicly accessible, thus providing unauthenticated users with privileges to access and abuse it through brute-force attacks, known CVEs and DDoS attacks—thereby exposing sensitive data. This risk will also impact the organization’s ability to comply with international regulatory requirements and should be a high-priority configuration when creating and maintaining such resources.

The screenshot below presents recommended network (public) access and default port configuration from an RDS datastore creation process.

Weak Encryption: Encryption of sensitive data—both at rest and in transit—is a necessary security baseline to ensure the integrity and confidentiality of organizational data and make it inaccessible to unauthorized users. Common encryption misconfigurations may include implementing inadequate encryption for communication channels such as TLSv1.2 (and higher), weak cipher suites or untrusted CA which may lead to a false sense of security. For data at rest, another common misstep is a lack of key rotation or exposure of the encryption key to unauthorized entities.

The screenshot below presents the recommended basic encryption-at-rest configuration to be enforced when creating an RDS datastore.

The screenshot below presents recommended basic encryption-in-transit configuration to be enforced when creating an RDS datastore.

Improper Authentication & Authorization (RBAC): A cornerstone of adequate data security hygiene is ensuring that access is only associated with a unique account based on the principle of least-privilege, using strong identification methods with appropriate justification. With RDS, users may not use IAM accounts, provide over-privileged access and permissions to either the main instance or to backups and refrain from implementing a user-access quarterly review.

The screenshot below presents the recommended authentication configuration to be enforced when creating an RDS datastore.

Incomplete Audits: Visibility cannot be considered a point-in-time activity. Monitoring of access and use of sensitive data is an essential component of tracking organizational assets and will provide crucial information in case of an incident or potential data breach. Incomplete or misplaced audit records including login/logout events, short-lived audits or leakage of sensitive data from RDS to audit logs increases the risk.

The screenshot below presents the recommended audit and log configurations when creating an RDS datastore.

Misconfigurations and single points of failure in cloud environments may be unavoidable for all organizations, especially those operating at scale, due to knowledge gaps, high velocity of data and changes and a lack of visibility as the amount of data increases. While the security baseline may be covered by RDS configurations, these are only the minimum required to protect your environment. DevSecOps teams are encouraged to work closely with their compliance leads to ensure that customer data is secured; leveraging RDS for its benefits is a complex and entirely more substantial responsibility. Organizations must view their data as an inherent part of their internal assets. As its owner, they should create appropriate ecosystems that allow continuous oversight and monitoring of the data, gaps that may arise and, most importantly, the controls in place to secure it.

June 29, 2022
Hasura SDK Integrates GraphQL Platform With More Data Sources

At its HasuraCon ’22 conference, Hasura today announced the early release of a software development kit (SDK) that extends the reach of its GraphQL platform to additional data sources.

In addition, Hasura is making generally available integrations with the GitHub repository, support for OpenTelemetry Traces within the Hasura Cloud Platform and Microsoft SQL event triggers.

Finally, Hasura Cloud can now be deployed on the Google Cloud Platform while the Hasura Cloud Enterprise edition is now available on the Amazon Web Services (AWS) marketplace.

Hasura CEO Tanmai Gopal said that while the company already provides support for widely used data sources such as the Postgres database, there are many data sources that organizations also want to be able to query via GraphQL application programming interfaces (APIs). Organizations want to be able to join data using GraphQL regardless of what repository it resides in, he added.

The open source Hasura engine at the core of the company’s offerings automatically generate a GraphQL schema from a data source. That can then be used to accelerate the development of APIs to make it easier for a wider range of developers to build applications that aggregate data across multiple sources.

That approach eliminates the backend complexity that IT teams encounter when adding GraphQL APIs to an application environment that already has a range of APIs for internal IT teams to support, noted Gopal.

GraphQL was originally created by Facebook, but it’s still not clear to what degree GraphQL APIs will supplant REST APIs. Developers tend to prefer GraphQL APIs because they provide more granular control over what data is accessed. The challenge is the number of backend services that expose GraphQL APIs is still comparatively limited.

It’s not likely IT teams will replace REST APIs with GraphQL-based APIs overnight, but the percentage of new applications that rely on GraphQL APIs will steadily increase. Overall, the number of APIs employed within IT environments is rapidly expanding as more microservices-based applications are deployed. Each microservice generates its own API. Over time, IT teams will find themselves managing a wider variety of types of APIs.

The challenge is that it’s not always clear who within IT organizations will manage those APIs. They are often created by developers and are left to IT operations teams to maintain. It’s not uncommon for IT teams to find themselves managing hundreds, perhaps thousands of APIs.

In addition, many of those organizations are now consuming data via APIs exposed by other organizations. Over time, the level of interdependency between APIs and applications will serve to make application environments much more complex to manage.

In the meantime, DevOps teams will need to extend existing DevOps workflows to both support and secure GraphQL-based APIs. The amount of sensitive data being accessed via those APIs is likely to accelerate the rate at which organizations are adopting DevSecOps best practices. Let’s hope this happens before they wake up to discover GraphQL APIs have already proliferated across the enterprise.

June 28, 2022