Author: ultroni1

Only give access to people who really need it, and only for as long as they need it.

Even trusted users shouldn’t have open-ended access. Keep permissions tight and time-limited, so the system stays protected from misuse or mistakes.

Contoso’s challenge

• Contoso Rise Up is known for great customer support. To help troubleshoot quickly, the support team has full access to customer data.
• The support team is regularly trained on ethical access.
• Unfortunately, one upset employee broke that trust. They copied and publicly shared a donor list. The person was fired, but the damage to Contoso Rise Up’s reputation was already done.

Applying the approach and outcomes

• Contoso Rise Up strictly grouped users in Microsoft Entra ID and set up role-based access (RBAC) to control who can access what.
• All data access now requires approval, is time-limited, and gets logged.
• These rules apply across the workload and customer support teams, so there’s no more standing access to customer data.

Identify confidential data through classification

Figure out what kind of data you have, how sensitive it is, and what could go wrong if it got out. Label the data accordingly so that you can apply the right level of protection where needed.

This evaluation helps you rightsize security measures. You can also identify high-risk data and components that might affect your workload or be exposed. This exercise helps get everyone on the same page about how to handle different types of data.

Contoso’s challenge

• The donor management system stores many different types of data:
  • Internal information like Contoso Rise Up’s customer list
  • Customer-owned data like donor lists
  • Donor-specific data like mailing addresses
  • Nonsensitive data like stock images and document templates
• The workload team hasn’t classified the data. They’ve applied security broadly across the dataset.

Applying the approach and outcomes

• The workload team follows Contoso’s data classification guidelines and flags data stores, columns, storage accounts, and other storage resources with metadata to indicate the type and sensitivity of the data.
• This activity helps make sure that each level of sensitive data is properly handled throughout the entire system, including logging statements and backups.
• The team finds relatively sensitive data in a lower security database and nonsensitive data in a higher security database. They’re reorganizing the data to match security levels with the data type.
• They also plan to use data masking on key fields to better protect data confidentiality, so even authorized users only see what they need.

Make sure there’s an incident response plan for your workload. Use industry frameworks that define the standard operating procedure for preparedness, detection, containment, mitigation, and post-incident activity.

During a crisis, avoid confusion by having a clear security incident response plan. Responsible roles can focus on execution without wasting time on uncertain actions. A comprehensive plan helps you meet remediation requirements.

Contoso’s challenge

• The workload team is setting up retailer support channels, customer support channels, and technical on-call rotations for support escalations and outages.
• They haven’t addressed security specifically and don’t know what Contoso offers for support.

Applying the approach and outcomes

• The workload team works with the Contoso security team to understand compliance requirements for handling personal data from both an organization perspective and external compliance perspective.
• The team builds a security detection, mitigation, and escalation plan, including communication for incidents.
• The team now feels just as comfortable with security incident preparedness as they do with their reliability support. They plan to practice handling incidents before they go live.

Codify secure operations and development practices

Set clear team-level security standards for your workload’s life cycle and operations, including how to write code, approve changes, release updates, and handle data.

Having robust security habits helps avoid mistakes and keeps things running smoothly. When everyone follows the same approach, it’s easier to stay on track and work efficiently.

Over time, sticking to these standards helps you spot ways to improve and maybe even automate steps to save time and boost consistency.

Contoso’s challenge

• After getting ready to handle incidents, the team realized they need to invest in preventing problems before they happen.
• They don’t have a specific secure development process yet. They plan to reuse processes that they used on past projects.

Applying the approach and outcomes

• This workload doesn’t store highly sensitive data like credit card information, but the team still treats their customers’ data with care. They’re aware of local and federal regulations that must be followed for the types of data that they store.
• The team invests in learning about current industry-standard secure development and operations practices and starts using measures that they hadn’t used before.
• The team also shares their learnings with the Contoso security team so that everyone across the company can benefit from the improvements.

Use segmentation to plan security boundaries in the workload environment, processes, and team structure to isolate access and function.

Base your segmentation strategy on business needs, like the importance of components, division of labor, privacy concerns, and other factors.

To reduce operational friction, define roles and responsibility clearly. This exercise helps you identify the level of access for each role, especially for important accounts.

Isolation limits exposure of sensitive flows to only roles and assets that need access. Too much exposure can lead to information leaks.

Contoso’s challenge

• In the spirit of simplicity, the team has historically favored low overhead approaches. These approaches have included grouping components and organizing individuals into security groups to simplify access management.
• A QA intern had broad access because of their security group membership. Unfortunately, their account was compromised in a social engineering attack.
• This attack compromised the confidentiality of that deployment and all other deployments on the same application platform.

Applying the approach and outcomes

• Luckily, the compromised environment was just an early test prototype for the new customer loyalty program, so no production systems were affected.
• The security team plans to invest time and money to isolate components that handle personal data, like addresses and emails, from components that don’t, like coupons. They’ll design access controls that are need-to-know and just-in-time (JIT) where possible, and isolate networks within the workload and back into Contoso to protect the organization.
• Segmentation helps contain the impact of a compromise.

By adding multiple APIs, functions, and other services to API Management, you can assemble those components into an integrated product that presents a single entry point to client applications. Composing an API using API Management has advantages that include:

• Client apps are coupled to the API expressing business logic, not the underlying technical implementation with individual microservices. You can change the location and definition of the services without necessarily reconfiguring or updating the client apps.
• API Management acts as an intermediary. It forwards requests to the right microservice regardless of location and returns responses to users. Users never see the different URIs where microservices are hosted.
• You can use API Management policies to enforce consistent rules on all microservices in the product. For example, you can transform all XML responses into JSON, if that is your preferred format.
• Policies also enable you to enforce consistent security requirements.

API Management also includes helpful tools – you can test each microservice and its operations to ensure that they behave in accordance with your requirements. You can also monitor the behavior and performance of deployed services.

Azure API Management supports importing Azure Function Apps as new APIs or appending them to existing APIs. The process automatically generates a host key in the Azure Function App, which is then assigned to a named value in Azure API Management.

Microservices architectures can be difficult to manage. For example, you might rely on separate teams implementing cross-cutting requirements, such as security, in a consistent way.

In the online store, your developer teams built the product details and order details microservices at different host URLs. Also, the order details service responds by using XML. You want to ensure that all responses are in JSON format to make things easier for the client app developers.

In this unit, you learn about the features of API Management. You can use these features to integrate different microservices and present them to client applications with consistent behavior at a single URL.

Microservices architecture challenges

The microservices approach to architecture creates a modular application in which each part is loosely coupled to the others. Independent deployment of services reduces the effect of any bugs that might make it through testing into production. This modular approach makes it easier to roll back to a stable version. Also, you can create small, autonomous teams of developers for each microservice. This division fits well with modern Agile practices.

However, microservices architectures can also present challenges, such as:

• Client apps are coupled to microservices. If you want to change the location or definition of the microservice, you might have to reconfigure or update the client app.
• Each microservice can be presented under different domain names or IP addresses. This presentation can give an impression of inconsistency to users and can negatively affect your branding.
• It can be difficult to enforce consistent API rules and standards across all microservices. For example, one team might prefer to respond with XML and another might prefer JSON.
• You’re reliant on individual teams to implement security in their microservice correctly. It’s difficult to impose these requirements centrally.

Azure Functions is a service that enables serverless architectures in Azure. You can write functions without worrying about the supporting infrastructure in many different languages, including C#, Java, JavaScript, PowerShell, and Python. You can use libraries from NuGet and the Node Package Manager (npm). You can also authenticate users with the OAuth standard from providers such as Active Directory, Facebook, Google, and Microsoft Account.

When you write a function, you choose a template to use depending on how you want to trigger your code. For example, if you want to execute the function in response to an HTTP request, use the HTTPTrigger template. You can use other templates to execute when there are new messages in a queue, a Blob storage container, or on a predefined schedule.

When you use Azure Functions in a Consumption Plan, you’re charged only for the time that your code runs.

Azure API Management

Azure API Management is a fully managed cloud service that you can use to publish, secure, transform, maintain, and monitor APIs. It helps organizations publish APIs to external, partner, and internal developers to unlock the potential of their data and services. API Management handles all the tasks involved in mediating API calls including request authentication and authorization, rate limit and quota enforcement, request and response transformation, logging and tracing, and API version management. API Management enables you to create and manage modern API gateways for existing backend services no matter where they’re hosted.

Because you can publish Azure Functions through API Management, you can use them to implement a microservices architecture; each function implements a microservice. By adding several functions to a single API Management product, you can build those microservices into an integrated distributed application. Once the application is built, you can use API Management policies to implement caching or ensure security requirements.

API Management Consumption Tier

When you choose a usage plan for API Management, you can choose the consumption tier. The consumption tier is especially suited to microservice-based architectures and event-driven systems. For example, it would be a great choice for our online store web API.

The consumption tier uses the same underlying service components as the previous tiers, but employs an entirely different architecture based on shared, dynamically allocated resources. The consumption tier aligns perfectly with serverless computing models. There’s no infrastructure to manage and no idle capacity. It provides high-availability, automatic scaling, and usage-based pricing. All of which make the consumption tier an especially good choice for solutions that involve exposing serverless resources as APIs.

Agile and scrum training courses malaysia

The Azure API Management service enables you to construct an API from a set of disparate microservices.

In your online store, each part of the application is implemented as a microservice – one for the product details, one for order details, and so on. A separate team manages each microservice, and each team uses continuous development and delivery to update and deploy their code regularly. You want to find a way to assemble these microservices into a single product and then manage that product centrally.

In this unit, you learn how Azure API Management is useful in a serverless architecture by building single APIs from individual microservices.

Serverless architecture and microservices

Microservices are a popular approach to the architecture of distributed applications. When you build an application as a collection of microservices, you create many different small services. Each service has a defined domain of responsibility and is developed, deployed, and scaled independently. This modular architecture results in an application that is easier to understand, improve, and test. It also makes continuous delivery easier, because you change only a small part of the whole application when you deploy a microservice.

Another complementary trend in distributed software development is serverless architecture. In this approach, a host organization publishes a set of services that developers can use to run their code. The developers don’t have to concern themselves with the supporting hardware, operating systems, underlying software, and other infrastructure. Instead, the code runs in stateless computing resources triggered by requests. Costs are only incurred when the services execute, so you don’t pay much for services that are rarely used.

Azure Functions

Azure Functions is a service that enables serverless architectures in Azure. You can write functions without worrying about the supporting infrastructure in many different languages, including C#, Java, JavaScript, PowerShell, and Python. You can use libraries from NuGet and the Node Package Manager (npm). You can also authenticate users with the OAuth standard from providers such as Active Directory, Facebook, Google, and Microsoft Account.

When you write a function, you choose a template to use depending on how you want to trigger your code. For example, if you want to execute the function in response to an HTTP request, use the HTTPTrigger template. You can use other templates to execute when there are new messages in a queue, a Blob storage container, or on a predefined schedule.

When you use Azure Functions in a Consumption Plan, you’re charged only for the time that your code runs.

Adroid training courses malaysia

It’s common to find that a few users overuse an API. Sometimes, an API is overused to such an extent that you incur extra costs or that responsiveness to other users is reduced. You can use throttling (rate limiting) to help protect API endpoints by restricting the number of times an API can be called within a specified period.

The Census API, for example, is distributed to lots of government agencies, so the number of calls to the API can become significant. By applying a rate limit policy, we can enable a quick response to all requests so that it isn’t possible for a single client to use all the resources for the Census API.

In this unit, you learn how to use API Management policies to impose two types of throttling.

Limit by subscription throttling

Subscription throttling allows you to set the rate limits by a specific API operation. It doesn’t discriminate by the client. Instead, every request to the API or the specified operation is throttled in the same way. Using our Census API example, we could use subscription throttling to limit the number of times any of the APIs are called within a certain period. This configuration would result in clients receiving a 429 error when that limit was reached. The problem with this type of throttling is that it allows one client to use up all the requests before another client can use it.

For example, the following code demonstrates an example configuration that applies to all API operations. The limit is set to three calls per 15-second period:

XMLCopy

<rate-limit calls="3" renewal-period="15" />

Alternatively, this configuration can be used to target a particular API operation:

XMLCopy

<rate-limit calls="number" renewal-period="seconds">
    <api name="API name" id="API id" calls="number" renewal-period="seconds" />
        <operation name="operation name" id="operation id" calls="number" renewal-period="seconds" />
    </api>
</rate-limit>

Limit by key throttling

Key throttling allows you to configure different rate limits by any client request value. This type of throttling offers a better way of managing the rate limits as it applies the limit to a specified request key – often the client IP address. It gives every client equal bandwidth for calling the API:

XMLCopy

<rate-limit-by-key calls="number"
                   renewal-period="seconds"
                   increment-condition="condition"
                   counter-key="key value" />

The following example configuration limits the rate limit by the IP address of a request. Here, the limit is set to 10 calls per 60-second period:

XMLCopy

<rate-limit-by-key calls="10"
              renewal-period="60"
              increment-condition="@(context.Response.StatusCode == 200)"
              counter-key="@(context.Request.IpAddress)"/>

Organizations might need to adjust the information that an API publishes at short notice. For example, to comply with a change of legislation or address a new security threat.

The Census API example exposes details about the URL from which the API is being called. This information could allow a malicious user to attempt to access the census data by bypassing the API Management gateway and exposing a less secure endpoint. As lead developer, you want to mask these URLs within the response body of the API.

Here, you learn how to use API Management policies that manipulate the content of API response headers and bodies.

Why transform a response?

The response body of an API call contains the data that is being requested. In the Census API, for example, the response body contains the JSON data for the respondents. You can also see how the body contains URL links to view individual people:

These links are based on the Census API endpoints and need to be masked to show the API Management URLs instead.

Any organization that publishes an API needs to make sure that users can access it securely and that malicious users can’t successfully attack it.

Governments store much personal data regarding citizens. Census data reveals a lot about each citizen, and their life. This data could be exploited to harm people. It’s imperative that any data exposed through API endpoints are secured through modern standards.

As the lead developer, you look at how to set up a secured API gateway, which protects the census data from unauthorized access. It also helps protect the endpoints from denial-of-service attacks.

Azure API Management

The Azure API Management service is hosted in the Azure cloud and is positioned between your APIs and the internet. An Azure API gateway is an instance of the Azure API Management service.

Publishers of APIs use the Azure portal or other Azure tools to control how each API is exposed to consumers. For example, you might want some APIs to be freely available to developers, for demo purposes, and access to other APIs to be tightly controlled.