• Introduction
• TL;DR: Why RFC 9457?
• Let’s write some code!
  • 1. Hand-made ProblemDetail + ExceptionMapper
  • 2. Zalando Problem
  • 3. Quarkus: quarkus-http-problem
  • 4. Spring Boot – a short note
• Conclusion
• What’s Next?

Introduction

If you’ve consumed more than one or two REST APIs, you’ve seen the pattern. One service returns {"error": "..."}, another {"message": "...", "code": 42}, a third returns 200 OK with an error hidden somewhere deep in the response. Your REST client code fills up with special cases for each one. Sounds familiar?

RFC 9457 – Problem Details for HTTP APIs (the successor to RFC 7807) defines a single JSON envelope for errors, served as application/problem+json MIME type. It is a small spec: five well-defined bits of information and an extensions map for anything else you might need.

{
  "type": "urn:problem-type:validation-error",
  "title": "Validation Failed",
  "status": 400,
  "detail": "The request body or parameters failed validation.",
  "extensions": {
    "violations": [
      { "field": "title", "message": "Title is required" }
    ]
  }
}

TL;DR: Why RFC 9457?

Why not keep creating your own?

• Consumers already know the shape. Generated SDKs, gateways, log pipelines, and tracing tools can parse application/problem+json without extra work.
• You can extend it without breaking clients. The extensions map is part of the spec – put what you need in there.
• It separates the category from the instance. type says “this is a validation error” (stable, machine-readable); detail and instance describe what happened this time.

💡 Note: RFC 9457 is just a JSON structure and a content type. No library or framework is required. That’s why there are so many implementations – and why a hand-made one is often a reasonable choice.

Let’s write some code!

I have created a repository called API Guide for Java to showcase the patterns for one of my talks. For this post, have a look at ProblemDetail.java and the mappers next to it under com/mehmandarov/confapi/error/.

1. Hand-made ProblemDetail + ExceptionMapper

What it looks like

Imagine you have a REST interface looking like this:

@GET
@Path("/{id}")
@Operation(summary = "Get room by ID")
@APIResponse(responseCode = "200", description = "Room found")
@APIResponse(responseCode = "404", description = "Room not found")
public Room getById(
        @Parameter(description = "Room ID", required = true)
        @PathParam("id") String id) {
    return repo.findById(id)
            .orElseThrow(() -> new NotFoundException("Room not found: " + id));
}

Now, you can add a single ProblemDetail class – built around the five RFC 9457 elements and an extensions map – and one ExceptionMapper per error category.

public class ProblemDetail {
    private URI type = URI.create("about:blank");
    private String title;
    private int status;
    private String detail;
    private URI instance;
    private final Map<String, Object> extensions = new LinkedHashMap<>();

    public static ProblemDetail of(int status, String title) { /* ... */ }
    public ProblemDetail withType(String typeUri)            { /* ... */ }
    public ProblemDetail withExtension(String key, Object v) { /* ... */ }
    // + getters/setters
}

The interesting part is how it gets used. As you can see from the resource code above, there is no try/catch in resources, ever – every exception is turned into a Problem Details response by an ExceptionMapper:

@Provider
public class ConstraintViolationExceptionMapper
        implements ExceptionMapper<ConstraintViolationException> {

    @Override
    public Response toResponse(ConstraintViolationException ex) {
        List<Map<String, String>> violations = ex.getConstraintViolations()
                .stream().map(this::toMap).toList();

        ProblemDetail problem = ProblemDetail.of(400, "Validation Failed")
            .withType("urn:problem-type:validation-error")
            .withExtension("violations", violations);

        return Response.status(400)
                .type("application/problem+json")
                .entity(problem).build();
    }
}

One mapper per category keeps each file small and obvious: ConstraintViolationExceptionMapper → 400, NotFoundExceptionMapper → 404, NotAuthorizedExceptionMapper → 401, ForbiddenExceptionMapper → 403, and a CatchAllExceptionMapper → 500 that never leaks stack traces to clients.

⚠️A word of caution: The catch-all mapper is the safety net for everything you forgot to handle. Without one, an uncaught exception ends up in the server’s default error page, which often includes stack traces, server versions, and sometimes filesystem paths. However, it might be a good idea to handle most of the common exceptions explicitly, and leave the generic catch-all for something truly unexpected.

✅ Pros:

• Portable across runtimes. The same code runs on Quarkus, Helidon, and Open Liberty. No runtime-specific extension.
• No extra dependencies. RFC 9457 is just a JSON structure; you don’t need a library to emit one.
• Small, readable surface. The error model fits on one slide. When something goes wrong, you can read the source.

❌ Cons:

• You write the boilerplate yourself – one mapper per category.
• Nothing maps validation, WebApplicationException, or uncaught Throwable automatically – you wire each one up. (This can also be one of the pros, depending on the way you look at things.)
• No content negotiation between application/json and application/problem+json unless you add it yourself. (Spring, for example, has a built-in ProblemDetail that does this for you.)

💡 Want to know more? The full code, including all five mappers, lives in com/mehmandarov/confapi/error/.

2. Zalando Problem

What it looks like

The Zalando Problem library (org.zalando:problem + jackson-datatype-problem) gives you Problem and ThrowableProblem types and Jackson serialization. You still write an ExceptionMapper to bridge JAX-RS exceptions to Problem, but you don’t define the envelope yourself.

import org.zalando.problem.Problem;
import org.zalando.problem.Status;

Problem problem = Problem.builder()
        .withType(URI.create("urn:problem-type:validation-error"))
        .withTitle("Validation Failed")
        .withStatus(Status.BAD_REQUEST)
        .with("violations", violations)
        .build();

return Response.status(400)
        .type("application/problem+json")
        .entity(problem).build();

✅ Pros:

• Cross-runtime. Works on Quarkus, Helidon, and Open Liberty – the same artifact deploys on all three.
• Used in production at Zalando (and elsewhere); the model handles cause chains, stack-trace processing, and a few edge cases you probably would not have thought of upfront.
• Jackson integration is done for you via jackson-datatype-problem.

❌ Cons:

• One more dependency to track and upgrade.
• You still write the ExceptionMappers – the library standardises the payload, not the wiring.
• If your stack is JSON-B rather than Jackson, you have a bit of extra work.

3. Quarkus: quarkus-http-problem

If you’re only targeting Quarkus, the quarkus-http-problem Quarkiverse extension is the shortest path. It auto-maps ConstraintViolationException, WebApplicationException, and uncaught Throwable to application/problem+json with no boilerplate from you.

✅ Pros:

• Add the dependency and you get Problem Details for exceptions. No need to write a mapper for each of them.
• Reasonable defaults for validation and security exceptions.

❌ Cons:

• Quarkus only. Doesn’t help on Helidon (Jersey) or Open Liberty (CXF). If “runs on every Jakarta runtime” is a requirement, this is out.
• Less visibility into what gets mapped to what – fine until you need to override a default.

4. Spring Boot – a short note

For completeness, we need to mention Spring Boot 3+ as well, which has Problem Details built in as org.springframework.http.ProblemDetail, with content negotiation and @ExceptionHandler integration already wired up. If you’re on Spring, just use it. The JSON structure is the same RFC 9457; only the wiring differs.

Conclusion

The point of RFC 9457 is not that there’s one correct implementation – there are several reasonable ones – but that there’s one correct envelope. Once your API speaks application/problem+json, clients stop hand-coding error parsers for each new service they consume.

A few rules of thumb:

• On Spring, use the built-in ProblemDetail.
• On Quarkus only, reach for quarkus-http-problem and move on.
• For cross-runtime Jakarta, choose between Zalando Problem (one dependency, more handled for you) and the hand-made approach (no dependencies, about 30 lines you fully understand).

I picked the hand-made approach for the demo project because portability across Quarkus, Helidon, and Open Liberty mattered, and because the ExceptionMapper is the demo – hiding it behind a library would have defeated the point of the talk.

However, “hand-made” doesn’t have to mean “everyone reinvents it from scratch”. Write it once, put it in a small internal library, and reuse it across services. That’s still less code than wiring up a third-party dependency in each runtime.

Summary Comparison

What’s Next?

Error handling is one of the bonus topics in the API Guide for Java. The same repo also covers OpenAPI documentation, security (RBAC, JWT), pagination, async, and versioning strategies – see my earlier post on API versioning in Java using JAX-RS.

Happy shipping of well-formed error messages, folks!

• Introduction
• Why Versioning?
• Show Me The CODE!
• 1. URL Versioning
• 2. Header Versioning
• 3. Media Type Versioning
• 4. Request Parameter Versioning
• 5. Bonus: Combining Strategies
• 6. End-Point Deprecation
• Summary Comparison
• Conclusion
• What’s Next?

Introduction

When working with APIs over time we would often need to make some changes to end-point definitions – like adding or deleting resources or changing the attributes for a resource. To ensure backwards compatibility, we often have to introduce versioning for our APIs. APIs, like all software, evolve. You might be adding optional fields or introducing a breaking change. At some point, you will need versioning to support coexistence of the old and new consumers.

However, versioning the API endpoint introduces a question of how this should be done. In this post, we’ll explore several common API versioning strategies, using Jakarta EE and Java.

💡 Note: There is no silver bullet – instead, we’ll explore pros, cons, and real-world fit.

Why Versioning?

Why not just change the API?
Because breaking contracts is dangerous — clients may not update in sync, and you’ll break production consumers.

Versioning allows you to:

• Support legacy clients
• Introduce new features safely
• Deprecate responsibly

⚠️ Caution: Versioning can cause “version explosion.” Each version increases long-term maintenance cost – aka technical debt.

Best Practice: Prefer backward-compatible changes (e.g., adding fields) whenever possible. To mitigate risks, it’s important to follow best practices for versioning and provide clear documentation and migration paths for users. Also, remember to deprecate old versions to minimize maintenance efforts.

Show me the CODE!

I have created a repository called Random Strings to showcase various concepts. For this blogpost, I would recommend having a look at RandomStringsAPIDemoController.java and request_examples.http. You will find all the info on building and running the code in the repo’s README.md file. Each section below will contain “How to call it” part with an example using curl or HTTP-files, and will be based on this repo.

1. URL Versioning

What it looks like

A version appears directly in the URI path. If your API is at https://example.com/api, and the current version is version 1, the URL for a resource might look like this: https://example.com/api/v1/resource:

@GET
@Path("/v2/")
@Produces(MediaType.APPLICATION_JSON)
public Response getV2() {
    return Response.status(Response.Status.NOT_IMPLEMENTED)
        .entity("This v2 using *path versioning* of the API is not implemented.")
        .build();
}

How to call it

cURL:

curl -X GET http://localhost:8080/api/rnd/v2/ \
  -H "Accept: application/json"

HTTP Request (.http file):

GET http://localhost:8080/api/rnd/v2/
Accept: application/json

✅ Pros:

• Simple and intuitive. Visible.
• Easy to test (e.g., with curl or Postman directly in a browser).
• Plays well with gateways and reverse proxies.
• Clear visual distinction between versions.

❌ Cons:

• Pollutes the URI with versioning logic.
• Breaks REST’s principle of stable resource identifiers.
• Clients have to update URLs when migrating.
• Risk of accumulating too many legacy versions.
• Can result in cluttered and difficult-to-read URLs if there are multiple versions of the API.

🔍 However: Despite its REST purism flaw, URL versioning is extremely practical and widely adopted.

2. Header Versioning

What it looks like

Client specifies version in a custom HTTP header (e.g., Accept-Version, X-API-Version, etc.):

@Path("/hi2")
@GET
@Produces({"application/json"})
public String entryPoint2(@HeaderParam("Accept-Version") String apiVersion) {
    if (apiVersion == null || apiVersion.isEmpty()) {
        return "Default unversioned endpoint hit.";
    }
    String message = "Versioned: Using custom headers. Using version: " + apiVersion +".";
    return message;
}

How to call it

Note: This is for demo purposes only. It has to have a different URL than the regular API; otherwise, it will also intercept calls that do not contain the Accept-Version header.

cURL:

curl -X GET http://localhost:8080/api/rnd/versioned/ \
  -H "Accept: application/json" \
  -H "Accept-Version: 2"

HTTP Request (.http file):

GET http://localhost:8080/api/rnd/versioned/
Accept: application/json
Accept-Version: 2

✅ Pros:

• Keeps URL structure clean and predictable.
• Closer to HTTP semantics (headers = metadata).
• Allows centralized versioning logic in filters/interceptors.

❌ Cons:

• Not self-descriptive — clients must “know the secret handshake”.
• Poor discoverability (not visible in browser without tools).
• Breaks caching in some proxies/CDNs unless explicitly configured.
• Adds complexity to tooling and testing.

⚠️ Challenge: Header versioning can feel “invisible” and cause developer confusion if not well-documented.

3. Media Type Versioning (Content Negotiation)

What it looks like

Client specifies version via a custom media type in the Accept header. This is sometimes called Content Negotiation versioning.

Accept: application/hi.v3+json

In Jakarta EE:

@Path("/hi")
@GET
@Produces({"application/hi.v3+json", "application/hi.v4+json"})
public String entryPoint() throws URISyntaxException {
    String message = "Versioned: Hai there!";
    return message;
}

How to call it

You can request different versions (e.g., v3, v4, v5) by updating the media type:

cURL:

curl -X GET http://localhost:8080/api/rnd/ \
  -H "Accept: application/rnd.v3+json"

HTTP Request (.http file):

GET http://localhost:8080/api/rnd/
Accept: application/rnd.v3+json

✅ Pros:

• Very REST-compliant: changes representation, not resource.
• URI remains stable.
• Supports richer format negotiation (e.g., XML, HAL, etc.).

❌ Cons:

• Requires strict control over media types.
• Not all clients/tooling handle custom media types well.
• Breaks with some reverse proxies and middleware that don’t forward full Accept headers.
• More work to configure content negotiation.

🧪 Observation: Elegant in design, but rarely used consistently in real-world public APIs.

4. Request Parameter Versioning

What it looks like

Technically, it is also possible for the client to specify the version in a URL query parameter (e.g., ?version=2). This, however, might not be a suggested strategy, in my opinion.

https://example.com/api/resource?version=2

How to call it

cURL:

curl -X GET http://localhost:8080/api/rnd?version=2 \
  -H "Accept: application/json"

HTTP Request (.http file):

GET http://localhost:8080/api/rnd?version=2
Accept: application/json

✅ Pros:

• Simplicity & discoverability: Easy to test in a browser without specialized tools.
• Defaulting logic: Straightforward to implement “default to latest” if the parameter is omitted.
• Caching friendly: CDNs treat different query params as unique resources by default.

❌ Cons:

• URI Pollution: Mixes resource identification with technical metadata.
• Routing complexity: Routing based on query parameters usually requires custom middleware or manual logic inside the controller.
• Harder to generate clean, automated documentation (like OpenAPI) when multiple versions share the same path.

5. Bonus: Combining Strategies - Transparent URI Rewriting (Enterprise Pattern)

In large enterprises, you might find that different clients have different needs. Some prefer the explicitness of URL versioning, while others require the clean URIs of Header versioning. You don’t have to choose just one—you can support both without duplicating your backend routing logic.

The common practice is to structure all your resource classes using URL versioning (e.g., @Path("/v1/resource")), but use a @PreMatching Filter to intercept requests and transparently rewrite the URI if a client uses a header instead.

Here is what that looks like in Jakarta EE using a ContainerRequestFilter:

@Provider
@PreMatching
public class HeaderVersionFilter implements ContainerRequestFilter {

      @Override
      public void filter(ContainerRequestContext ctx) {
          String path = ctx.getUriInfo().getPath();

          // If the path is already versioned (e.g., starts with v1, v2), let it pass
          if (path.matches("v\\d+(/.*)?")) return;

          // Otherwise, check if the client provided a version header
          String version = ctx.getHeaderString("X-API-Version");

          if (version != null && !version.isEmpty()) {
              // Transparently rewrite the URI internally to match our URL-based routes
              String newPath = "v" + version + "/" + path;
              URI baseUri = ctx.getUriInfo().getBaseUri();
              URI newUri = UriBuilder.fromUri(baseUri).path(newPath).build();

              ctx.setRequestUri(baseUri, newUri);
          }
      }
}

✅ Pros:

• Ultimate Flexibility: Clients can use http://api.example.com/v2/resource OR http://api.example.com/resource with an X-API-Version: 2 header.
• Single Source of Truth: Your backend controllers only need to use @Path("/v2/"). You don’t have to write duplicate methods to handle both headers and paths.

❌ Cons:

• Magic Routing: It introduces a layer of “magic” where the requested URI differs from the routed URI, which can briefly confuse new developers debugging the application.

💡 Want to know more? Read up on terms Version Normalization and Internal Decoupling.

6. End-Point Deprecation

Eventually, you will need to retire old API versions. Remember: every old version you keep around is technical debt — it increases long-term maintenance cost. When deprecating an endpoint, consider the following best practices:

1. Update the Docs: Use OpenAPI’s @Operation annotation to clearly mark it as deprecated.
2. Add @Deprecated: Use the Java @Deprecated annotation where necessary.
3. HTTP Redirects: Consider returning HTTP codes like 302 Found or 301 Moved Permanently after some time.
4. Add a Link header: Provide a link to the new version in the response headers.
5. Log / Count calls: Track usage (e.g., with MicroProfile @Counted) to know when it is safe to finally remove the endpoint.

Here is a practical example in Jakarta EE showing how to deprecate an endpoint, add a Link header, and track metrics:

@GET
@Path("v0.1/")
@Produces(MediaType.APPLICATION_JSON)
@Operation(summary = "DEPRECATED. Use v2 now. Returns the adjective-noun pair",
           description = "Deprecated function. The pair of one random adjective and one random noun is returned as an array.")
@Counted(name = "totalCountToRandomPairCalls_Versioned_Path_DEPRECATED",
         absolute = true,
         description = "Deprecated function call: Total number of calls to random string pairs.",
         tags = {"calls=pairs"})
@Deprecated
public Response getRndStringPathDeprecated() {
    URI newVersionURI = UriBuilder.fromUri("/api/rnd/v2/").build();
    Link newVersionLink = Link.fromUri(newVersionURI).rel("alternate").build();
    return Response.ok("Deprecated response", MediaType.APPLICATION_JSON)
            .header(jakarta.ws.rs.core.HttpHeaders.LINK, newVersionLink.toString())
            .header("X-API-Version", "0.1")
            .build();
}

How to call it (Deprecated endpoint)

cURL:

curl -X GET http://localhost:8080/api/rnd/v0.1/ \
  -H "Accept: application/json"

HTTP Request (.http file):

GET http://localhost:8080/api/rnd/v0.1/
Accept: application/json

Summary Comparison

The following table summarizes all the different routing strategies implemented in the demo project, illustrating how the HTTP method, path, and headers combine to invoke the correct Java method. The method names refer to the methods in RandomStringsAPIDemoController.java (or RandomStringsController.java):

Conclusion

There is no single correct approach to API versioning. For most teams and public APIs, URL versioning is good enough—it’s visible, easy to test, and plays well with existing tooling. However, you might want to use header versioning if your APIs are primarily consumed by internal services or SDKs that can abstract away the complexity. Reserve media type versioning for hypermedia-rich or REST-purist APIs, and only if your tooling supports it end-to-end.

Consider who your consumers are, whether your API is public or internal, your infrastructure maturity, and your team’s ability to support multiple versions.

What’s Next?

Versioning is just one part of building robust REST APIs. If you want to dive deeper, have a look at the API Guide for Java repository and the slides in the presentation folder. They cover documentation with OpenAPI, security best practices (like RBAC and JWT integration), advanced patterns (pagination, async APIs), and going beyond REST with gRPC and GraphQL.

Happy coding!

• Introduction
• Principles
• Conclusion

Introduction

In the first part, we have summed up all the essential elements to consider when working with Cloud and securing cloud-native applications/platforms. In this post, we would like to give you some concrete principles and tips for creating more secure applications.

Principles

Multi-Layered Defense

Keywords: general

First of all, a more generic but important principle: It would be best to look at security as a whole – integrating various security layers on multiple levels in any system. It should include cyber-security plans for:

1. Devices
2. Applications
3. Networks
4. Infrastructure
5. People

Think of this principle as all the layers of clothing you wear to protect yourself from cold and bad weather. If one of the layers is compromised, there is always another to keep you warm and dry.

Identity and Access Management (IAM) Misconfiguration

Keywords: network, permissions

You need to control access and permissions meticulously and over time. Things to consider:

• Implementing role-based access control (RBAC)
• Principle of least privilege
• Routines for updating and removing permissions when they are no longer needed.
• Explore possibilities for using time-based conditions for IAM policies.

API Security

Keywords: endpoints, permissions

• APIs act as the gateways to your application and data. Securing access to and securing them from known vulnerabilities is paramount to prevent unauthorized access and data breaches.
• Utilize authentication, authorization, and API gateways to control access and protect sensitive information. Don’t forget to monitor the software or libraries that make APIs available (e.g., runtimes, middleware)

Data Encryption

Keywords: data

• Safeguarding data at rest, in transit, and during processing is critical for your applications.
• Utilize encryption, tokenization, and data masking techniques to ensure data protection. Removing unnecessary sensitive information can simplify some of these tasks.
• If a platform or a Cloud provider provides the encryption, consider if you would like to use the standard keys for encryption or “bring your own” and manage them yourself or through a third party.
• Beware: Don’t write your own crypto! Ever.

Zero Trust

Keywords: network, permissions

• The Zero Trust security model assumes that no one is inherently trustworthy, even those within your network.
• This is opposed to more traditional approaches where perimeter security was prioritized over security inside the network.
• Adopting this approach, every request, user, and device is thoroughly verified before gaining access.
• Again: Implement the principle of least privilege, where users are only granted the minimum level of access required to perform their tasks.

Software Supply Chain Security

Keywords: software, environment

• Create Software Bill of Materials (SBOM) for your software
• Governance: Know where all the building blocks (artifacts) of your software are coming from.
• Automate security checks within your CI/CD pipeline to catch vulnerabilities early and often.
• Use static code analysis with tools like SonarQube to scan your code for potential security flaws and integrate those checks into your CI/CD pipeline to ensure continuous security monitoring.
• Use tools to monitor not only the code you develop yourself but also all the third-party libraries you utilize in your code.
• With DevSecOps, automated security security is becoming integral to the development process. Adopt it if you haven’t done so already.

Secure Containerization

Keywords: software, environment

• Containerization and orchestration technologies, like Docker and Kubernetes, offer exceptional flexibility but also introduce security concerns.
• Securing containers and managing their lifecycle is vital to ensure a safe cloud environment.
• For example, use container scanning tools to identify vulnerabilities within container images before deploying them.
• Additionally, enforce strict security policies and segregate workloads using Kubernetes namespaces.

Continuous Monitoring and Incident Response

Keywords: software, environment

• The cloud landscape is constantly changing, and threats evolve rapidly. This means that we need to monitor not only for known threats but also for anomalies.
• Continuous monitoring and proactive incident response are essential to detect anomalies and respond swiftly to security incidents.
• For example, use cloud-native monitoring tools your Cloud or platform provider provides.
• Have good logging, but remember that more is not always better – log relevant information.

Human Factors (including Social Engineering, Misconfigurations, and Human Errors)

Keywords: people, human factors

• 82% of incidents are caused by human factors (2022 Data Breach Investigations Report)
• Creating secure applications also implies providing security training for the system users.
• Social engineering and human factor has proven to be essential to creating secure applications.
• Consider running security awareness campaigns and employee training from user and developer perspectives.
• Automate routine and mundane tasks – humans often don’t enjoy carrying out tasks like this and are prone to errors; computers, on the other hand, excel at tasks like this!

Conclusion

You have probably heard that nothing is stronger than its weakest link. Therefore, it is important to look at various sides of the security. Especially in the Cloud, one size does not fit all when it comes to security. Cloud platforms, software, and threats constantly evolve and add to the complexity of creating secure applications.

Here, we have seen some of the principles to consider regarding the security of the platforms and application development for the Cloud and cloud-native applications in general.

Finally, note that this is not an exhaustive list but is instead meant to serve as a stepping stone to more secure application development.

• Introduction
• Key Elements of a Cloud Security Architecture
• Responsibilities
• Constantly Evolving Landscape
• Platform Security Architecture
• Application Security Architecture
• Conclusion

Introduction

Whether you are running on the Cloud or not it is all about the CIA triad model – Confidentiality, Integrity, and Availability.

When thinking about Cloud Security Architecture we need to be able to think about the whole stack. Of course, we don’t need to think about all the moving parts alone – it is a shared responsibility between the Cloud service provider and you, the user of the platform.

Key Elements of a Cloud Security Architecture

Let’s first start by defining the key elements of a Cloud Security Architecture, divided across the layers of the stack, based on the Cloud Security Alliance (CSA) stack model.

Now, we can also mention some of the main challenges related to security, divided into separate groups, and try to map them to the CIA triad model that we have mentioned earlier.

Network and Storage

• Data Encryption
• Network Security

Application layer

• Application Security
• Logging and Monitoring
• Identity and Access Management (IAM)

Observability, and traceability

• Incident Response and Recovery
• Vendor and Third-Party Risk Management

DevOps

• Automation and Orchestration
• Resilience and High Availability

General

• Compliance and Governance
• User Training and Awareness
• Cloud Provider Security Features

Responsibilities

Shared Responsibility + Intersection of Responsibilities

Addressing all these challenges is a shared responsibility between the Cloud service provider and the customer and the division will vary depending on the type of the solution and whether you are using IaaS, PaaS, or SaaS.

Typically, Cloud service providers will take care of the lower parts of the stack, like physical, infrastructure, and platform security, while customers will be responsible for creating secure applications, securing their data, creating proper Identity and Access Management (IAM), and configuration management.

An effective overlap and a clear understanding of the responsibilities ensure comprehensive security coverage across all layers.

Constantly Evolving Landscape

Evolving Landscape == Constant Change

One of the differentiating factors from regular application development is the constant change and evolution of the platform and tooling on one side, and the constantly evolving types of attacks and possibly larger attack surfaces on the other side.

These factors will lead to changes in the model and the responsibility division. The same might be influenced by the new services being introduced both from the side of the Cloud service provider and the customer (app developer).

Therefore, regular communication between the parties involved and staying updated on their security practices is essential to ensure secure Cloud applications.

Types of the Cloud Security Architecture

The Cloud Security Architecture is twofold – you will need to choose a platform for running your application and think about the security of the application you will be deploying on that platform.

Platform Security Architecture

Let’s start with defining the types of platforms and list some of the key elements to consider when choosing a platform type.

Public Cloud Security Architecture

• Designed for cloud services provided by third-party vendors (e.g., AWS, Azure, Google Cloud).
• Focuses on securing data and applications hosted on shared infrastructure.
• Utilizes the security features provided by the cloud service provider (CSP) while also implementing * additional security measures.
• Emphasizes network segmentation, encryption, IAM, and monitoring.

Private Cloud Security Architecture

• Created for cloud environments dedicated to a single organization.
• Offers more control over security settings and configurations.
• Often used by organizations with strict compliance requirements or sensitive data.
• Implements strong access controls, encryption, and strict network isolation.

Hybrid Cloud Security Architecture

• Combines public and private clouds to take advantage of the benefits of both deployment models
• Security architecture addresses integration challenges and ensures consistency across environments
• Emphasizes secure communication between on-premises and cloud components
• Requires seamless identity and access management across both environments

Multi-Cloud Security Architecture

• Involves using services from multiple cloud providers simultaneously
• Ensures compatibility and security across diverse cloud platforms
• Requires careful management of authentication, authorization, data protection, and compliance measures
• Aims to prevent vendor lock-in and distribute risk

Application Security Architecture

Here are some things you will need to think about when developing modern applications for the Cloud and the cloud-native world.

1. Secure Your Code

• Software Supply Chain Security: Securing and monitoring your artifacts and third-party libraries.
• Making sure the code you have written is secure: OWASP Top 10, static code analysis, coding best practices.

2. Your Container (and Serverless) Security Architecture

• Specifically addresses security for containerized applications (e.g., Containers, Kubernetes) and serverless computing (e.g., AWS Lambda, Azure Functions, Cloud Functions, or Cloud Run on Google Cloud)
• Focus on securing microservices, communication between them, their orchestrators, and function-as-a-service (FaaS) platforms
• Involves isolating containers, securing images, and managing runtime security

3. Add DevSecOps Architecture Practices

• Integrate security practices into the DevOps process: DevSecOps
• Ensure security is considered at every stage of application development and deployment
• Involves automated security testing, vulnerability scanning, and security policy enforcement

4. Cross-application and Cross-container communication: Zero Trust Security Architecture

• Assume no trust by default and require strict authentication and authorization for all users and devices
• Focus on identity verification, principle of least privilege, and continuous monitoring
• Suitable for cloud environments where traditional perimeter defenses are less effective

5. Physical security: Edge Cloud Security Architecture

• Address security concerns at the edge of the network, closer to where data is generated and consumed
• In case of having local edge hardware devices consider also physical security of those devices
• Involves considerations like local processing, secure communication, and protection against threats targeting edge devices

6. Compliance-Centric Security Architecture

• Tailored to meet specific regulatory compliance requirements (e.g., GDPR, HIPAA, PCI DSS)
• Focus on implementing controls and safeguards to adhere to relevant standards

Conclusion

We have seen the key elements of the cloud security architecture and the building blocks of the whole stack. Furthermore, we have looked at the various types and elements to consider when it comes to the security of the platforms and application development. This is a stepping stone to categorize and group some of the main things you will need to consider when working with the Cloud and cloud-native applications.

** Illustrations in this post: Rustam Mehmandarov.