Protegendo o backend com Azure API Management

by Contributed | Mar 7, 2022 | Technology

This article is contributed. See the original author and article here.

Protegendo o backend com o Azure API Management

O Azure API Management é uma excelente opção para projetos que lidam com APIs. Estratégias como centralização, monitoria, gerenciamento e documentação são características que o APIM ajuda você a entregar. saiba mais.

No entanto muitas vezes esquecemos que nossos backends precisam estar protegidos de acessos externos. Pensando nisso vamos mostrar uma forma muito simples de proteger seu backend usando o recurso de private endpoint, VNETS e sub-redes. Assim podemos impedir chamadas públicas da internet no seu backend, porém permitindo que o APIM o acesse de forma simples e transparente.

O primeiro passo é entender a VNET, que é a representação virtual de uma rede de computadores, ela permite que os recursos do Azure se comuniquem com segurança entre si, com a Internet e com redes locais. Como em qualquer rede, ela pode ser segmentada em partes menores chamadas sub-redes. Essa segmentação nos ajuda a definir a quantidade de endereços disponíveis em cada sub-redes, evitando conflitos entre essas redes e diminuindo o tráfego delas. Observe o desenho abaixo:

Diagrama com uma VNET de CIDR 10.0.0.0/16 e duas sub-redes com CIDR 10.0.0.0/24 e 10.0.1.0/24.

É importante entender quais opções de conexão com uma VNET (Modos) o APIM oferece:

Off: Esse é o padrão sem rede virtual com os endpoints abertos para a internet.

Externa: O portal de desenvolvedor e o gateway podem ser acessados pela Internet pública, e o gateway pode acessar recursos dentro da rede virtual e da internet.

Interna: O portal de desenvolvedor e o gateway só podem ser acessados pela rede interna. e o gateway pode acessar recursos dentro da rede virtual e da internet.

Em um ambiente de produção essa arquitetura contaria com um firewall de borda, tal como um Application Gateway ou um Front Door, essas ferramentas aumentam a segurança do circuito oferecendo proteções automáticas contra os ataques comuns, por exemplo, SQL Injection, XSS Attack (cross-site scripting) entre outros. No entanto para fins de simplificação vamos ficar sem essa proteção.

A configuração de rede do APIM pode ser feita no menu lateral Virtual Networking, no portal de gerenciamento do Azure.

APIM com configuração externa na VNET vnet_apim e sub-rede SUBNET_APIM

Depois de configurar o APIM, devemos configurar o App Services. Nele vamos até o menu Networking e configuramos um private endpoint, é com esse recurso que associamos um App Services a uma VNET e uma sub-rede. Durante essa configuração é importante marcamos a opção que integra com um DNS privado, para garantir a resolução de nomes dentro da rede privada.

Portal do Azure, configuração do private endpoint do App Services

Agora podemos conferir que foi criado um private zone para o domínio azure.websites.net apontando para o IP privado do App Services, isso permite que o APIM acesse o App Services de forma transparente, assim como era antes da implementação da VNET.

Para realmente termos certeza de que nosso App Services está protegido, podemos tentar acessar seu endereço pelo navegador, algo como a imagem abaixo deve acontecer. Não vamos conseguir resolver esse DNS.

Acessando URL do APP Services pelo navegador, e recebendo um erro de resolução de DNS.

No entanto as APIs do APIM continuam funcionando com o mesmo endereço, já que o APIM está na mesma VNET que o App Services e o DNS privado resolve os nomes para endereços dessa VNET.

Tela do APIM com mesmo backend que não pode ser acessado pelo browser.

Usando a ferramenta de Teste do APIM podemos confirmar que o APIM consegue acessar o back-end.

Explorando a opção de Teste do APIM.

Conclusão

A implantação da Rede Virtual do Azure fornece segurança aprimorada, isolamento e permite que você coloque seu serviço de gerenciamento de API em uma rede protegida da Internet. Todos os acessos como portas e serviços podem ser controlados pelo NSG da VNET, dessa forma você garante que suas APIS serão acessadas apenas pelo endpoint de gateway do APIM.

Referências

https://docs.microsoft.com/pt-br/azure/api-management/api-management-using-with-vnet

https://docs.microsoft.com/en-us/azure/api-management/api-management-using-with-internal-vnet

https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-overview

This NCPW, help reach every community

by Scott Muniz | Mar 7, 2022 | Security

This article was originally posted by the FTC. See the original article here.

We know scammers target people everywhere. So this National Consumer Protection Week, we’re focusing on how fraud affects every community. In blog posts and events this week, we’ll highlight scams that affect some of those communities, including older adults, college students, servicemembers, and LGBTQ+ communities. Since scammers target every community, including yours, you can make a difference this NCPW: recruit your friends, family, and neighbors across all communities to report the scams they’re seeing to us.

The way fraud affects every community can look different across different demographic groups. For instance, the FTC’s Serving Communities of Color Report highlights some of the unique ways that people experience fraud in Black and Latino communities.

Here are just two examples of the differences we saw:

Fraud and bad business practices play out differently in different communities. The FTC’s reporting data showed that the top percentage of reports by people living in majority White and majority Latino communities were about impersonator scams. In majority Black communities, the top percentage of reports were about credit bureaus.
Scammers tell people to pay in different ways. Reports from majority Black and Latino communities show that people are more likely to end up paying scammers in ways that have few, if any, fraud protections ― so: cash, cryptocurrency, money orders, and debit cards. In contrast, reports from majority White communities show that people are more likely to pay scammers with credit cards.

Throughout the week, we’ll talk more about how fraud looks different across different communities. But today is about your community. Please remind your friends, family, and neighbors: if they see a scam, tell the FTC at ReportFraud.ftc.gov. And tune in for the rest of the week’s posts, and check out #NPCW2022 events at ftc.gov/ncpw. We hope to see you at some of them.

Brought to you by Dr. Ware, Microsoft Office 365 Silver Partner, Charleston SC.

Build high confidence migration plans using Azure Migrate

by Contributed | Mar 6, 2022 | Technology

This article is contributed. See the original author and article here.

Build high confidence migration plans using Azure Migrate’s software inventory and agentless dependency analysis

Authored by Vikram Bansal, Senior PM, Azure Migrate

Migrating a large & complex IT environment from on-premises to the cloud can be quite daunting. Customers are often challenged with the problem of unknown where they may not have complete visibility of applications running on their servers or the dependencies between them, as they start planning their migration to cloud. This results not only in leaving behind dependent servers causing the application to break, but also adds up to the migration cost that the customers want to reduce. Azure Migrate aims at helping customers build a high-confidence migration plan with features like software inventory and agentless dependency analysis.

Software inventory provides the list of applications, roles and features running on Windows and Linux servers, discovered using Azure Migrate. Agentless dependency analysis helps you analyze the dependencies between the discovered servers which can be easily visualized with a map view in Azure Migrate project and can be used to group related servers for migration to Azure.

Today, we are announcing the public preview of at-scale, software inventory and agentless dependency analysis for Hyper-V virtual machines and bare-metal servers.

How to get started?

To get started, create a new Azure Migrate project or use an existing one.

Deploy and configure the Azure Migrate appliance for Hyper-V or for bare-metal servers.

Enable software inventory by providing server credentials on the appliance and start discovery. For Hyper-V virtual machines, appliance lets you enter multiple credentials and will automatically map each server to the appropriate credential.

The credentials provided on the appliance are encrypted and stored on the appliance server locally and are never sent to Microsoft.

As servers start getting discovered, you can view them in the Azure Portal.

Software inventory

Using the credentials provided, the appliance gathers information on the installed applications, enabled roles and features on the on-premises Windows and Linux servers.

Software inventory is completely agentless and does not require installing any agents on the servers.

Software inventory is performed by directly connecting to the servers using the server credentials added on the appliance. The appliance gathers the information about the software inventory from Windows servers using PS remoting and from Linux servers using SSH connectivity.

Azure Migrate directly connects to the servers to execute a list of queries and pull the required data once every 12 hours.

A single Azure Migrate appliance can discover up to 5000 Hyper-V VMs or 1000 physical servers and perform software inventory across all of them.

Agentless dependency analysis

Agentless dependency analysis feature helps in visualizing the dependencies between your servers and can be used to determine servers that should be migrated together.

The dependency analysis is completely agentless and does not require installing any agents on the servers.

You can enable dependency analysis on those servers where the prerequisite validation checks succeed during software inventory.

Agentless dependency analysis is performed by directly connecting to the servers using the server credentials added on the appliance. The appliance gathers the dependency information from Windows servers using PS remoting and from Linux servers using SSH connection.

Azure Migrate directly connects to the servers to execute a list of ‘ls’ and ‘netstat’ queries and pull the required data every 5 mins. The appliance aggregates the 5 min data points and sends it to Azure every 6 hours.

Using the built-in dependency map view, you can easily visualize dependencies between servers. You can also download the dependency data including process, application, and port information in a CSV format for offline analysis.

Dependency analysis can be performed concurrently on up to 1000 servers discovered from one appliance in a project. To analyze dependencies on more than 1000 servers from the same appliance, you can sequence the analysis in multiple batches of 1000.

Workflow and architecture

The architecture diagram below shows how software inventory and agentless dependency analysis works. The appliance:

discovers the Windows and Linux servers using the source details provided on configuration manager

collects software inventory (installed applications, roles and features) information from discovered servers

performs a validation of all prerequisites required to enable dependency analysis on a server. The validation is done when appliance performs software inventory. Users can enable dependency analysis only on those servers where the validation succeeds, so that they are less prone to hit errors after enabling the dependency analysis.