DEV Community: Ezekiel Umesi

The Dangerous Comfort of the Checkbox: Why Compliance is Not Security

Ezekiel Umesi — Fri, 19 Sep 2025 01:17:07 +0000

If you work in cloud, risk, or leadership, you know the grueling effort required to align an environment with frameworks like SOC 2, ISO 27001, HIPAA, or PCI DSS. Teams spend months configuring guardrails, tightening IAM policies, and documenting controls. When the audit report finally comes back clean, it feels like a definitive win.

A successful audit proves your organization takes governance seriously. It builds customer trust, unblocks enterprise deals, and validates that your AWS workloads meet rigorous industry standards.

But there is a dangerous assumption lurking behind that clean report: the belief that because an environment is compliant, it is automatically secure.

In the cloud, compliance means you have implemented the required controls. Security, however, means those controls remain effective against real-world threats.

AWS provides a powerful arsenal—IAM, CloudTrail, GuardDuty, and Security Hub—but tools are not a strategy. They must be continuously monitored and aligned with evolving threat models, not just a static checklist. The real work begins the moment the audit ends—when the focus shifts from "Are we compliant?" to "Are we resilient?"

That is exactly the point where many organizations stumble. Thinking of compliance as a "finish line" rather than a "baseline" creates a false sense of security that sophisticated attackers love to exploit.

To bridge the gap between a clean audit and a truly hardened environment, you have to look at how these two worlds interact within the AWS ecosystem.

Why Saying "Compliance = Security" is Wrong and Dangerous

1. Compliance Looks Backward. Threats Come from the Future.

Compliance rules are based on what we already know. They are written from past best practices, often in response to the last major attack. They are very good at solving yesterday's problems.

But attackers live in the present and future. They are always inventing new methods, finding unknown vulnerabilities (zero-days), and creating clever tricks to fool people. These new threats won't be on any compliance checklist.

Compliance asks: "Do you have a rule for firewalls?" and "Do you force password changes every 90 days?"
Security asks: "Is our firewall set up to stop this new data theft method?" and "Are our people prepared for the latest phishing email that can get around multi-factor authentication (MFA)?"

Compliance checks the rearview mirror. Security has to watch the road ahead for dangers that are not on the map.

2. Compliance is the Minimum, Not the Goal

Compliance standards are made so that many different companies can meet them. They set a baseline, a starting point, and not the finish line. They are the lowest level of security needed to be in an industry.

If you make this minimum your main goal, you are not aiming high enough. You are building a wall that is just high enough to pass inspection, while attackers are building taller ladders.

Real security is a culture of always getting better. It means adding layers of defense, planning for a breach, actively looking for threats, and using advanced tools that compliance rules might not talk about, like Zero-Trust or Endpoint Detection and Response (EDR).

3. The Checkbox Mindset vs. The Security Mindset

This is the core of the problem. The process of passing an audit encourages a "checkbox mindset." The goal becomes to prove you have a control, not to make sure that control actually works well.

Checkbox Mindset: "Yes, we have a plan for what to do in a cyber attack." (The plan is a long document that no one has read or practiced).
Security Mindset: "Let's practice our response to a ransomware attack in a drill. Let's see if our team knows what to do when under real pressure."

One is about having paperwork. The other is about being ready to act. You can check every box and still have a security program that fails completely during a real attack.

4. Your Audit Scope vs. Your Real Attack Surface

A compliance audit has a defined "scope." This usually includes your main cloud servers and work laptops. It often excludes things like test systems, third-party apps, unauthorized software, or employees' home networks.

An attacker does not care about your audit scope. Their target is your entire attack surface. They will happily attack a weak point in a marketing tool, find a mistake in a test environment, or trick an employee on their home computer. If you only protected what was in your audit scope, you have left many other doors unlocked.

How to Build a Truly Secure Program

So, if compliance isn't security, what should you do? Should you stop doing audits? No. Compliance is still very important. You just need to use it the right way.

Use Compliance as a Foundation, Not the Finish Line. Let standards like SOC 2 give your security program a basic structure. Think of the certificate as a ticket that lets you into the game, not the prize for winning it.
Focus on Always Getting Better. Change the question in your company from "Are we compliant?" to "Are we secure?" Test yourself against real-world attack scenarios, not just a list of controls. Invest in training, threat information, and proactively searching for hackers.
Focus on Results, Not Rules. Don't just set up a security control; test how well it works. Is our MFA actually blocking attacks? Can we actually restore our backups quickly after an attack? This shifts the goal from proving you have a tool to proving it works.
Assume You Are Already Hacked. This is the biggest change in thinking. Operate as if an attacker is already inside your network. This makes you invest in what matters most: finding threats quickly, responding effectively, and recovering fast. These skills are often overlooked in compliance rules but are essential for survival.

Conclusion: The Map and the Territory

Compliance is the license to operate, but security is the will to survive. In AWS, your audit report proves you have the tools; your operational cadence proves you know how to use them when the sirens go off.

Shifting Security Left: Why DevSecOps is Not Optional Anymore

Ezekiel Umesi — Fri, 19 Sep 2025 00:57:16 +0000

For a long time, software development and security were separate. Development teams focused on building features quickly. Security teams focused on finding risks and vulnerabilities. They worked in silos. Developers would finish an application and then "throw it over the wall" to the security team for testing right before launch. This caused last-minute panic to fix issues, delayed releases, and frustrated everyone.

This old way of working is no longer just inefficient; it's unsafe. Today, cyberattacks are common, and one software weakness can lead to a major data breach. Security can't be an afterthought. It must be built into every step of the development process. This is the main idea behind DevSecOps—and it is now essential for any company that creates software.

What Does "Shifting Left" Mean?

"Shifting left" means adding security checks early and throughout the entire software building process (the Software Development Lifecycle, or SDLC). Instead of one big security test at the end, security happens at every stage:

Code: A developer writes code. Security starts here with tools in their coding software that scan for mistakes or exposed secrets (like passwords) before the code is even shared.
Build: When code is saved to a shared repository, automated processes begin. Tools called SAST scan the source code to find flaws like SQL injection.
Test: In the testing phase, other tools run automatically:
- DAST tools test the running application for vulnerabilities.
- SCA tools scan all the open-source building blocks (libraries) the app uses for known security holes.
Deploy: Before the app goes live, tools scan the infrastructure setup (like cloud server configurations) to ensure nothing is accidentally left open to the internet.
Operate: After launch, security continues with monitoring for suspicious activity.

Why You Must Use DevSecOps Now: The Real Reasons

Modern Development is Too Fast for Old Security
Teams now release software multiple times a day. A security review that takes two weeks cannot work in this model. Automated security tools that work inside the development pipeline can keep up without slowing things down.
Fixing Bugs Later Costs Much More
Fixing a vulnerability while writing code might take minutes. Fixing the same bug after the app is built might take an hour. If found after release, the cost includes downtime, breach cleanup, legal fines, and lost customer trust. Finding issues early is far cheaper.
Third-Party Code is a Major Risk
Attacks like the one on Log4j showed us that applications are built using many open-source parts. You must know if these parts have known weaknesses. An SCA tool that automatically checks for these vulnerabilities is now a basic requirement for safety.
Cloud Systems Create New Risks
Modern apps run in the cloud using containers and microservices. A single setting mistake can expose huge amounts of data. Because this infrastructure is controlled by code, we must scan that code for errors before it ever gets deployed.
It Empowers Developers
DevSecOps isn't about making developers security experts. It's about giving them automated tools to find problems themselves, early on. This helps developers build more secure software and creates a better partnership with the security team.

How to Start: A Practical Approach

You don't have to do everything at once. Start small:

Automate One Thing: Begin by adding one automated scanner (like an SCA or SAST tool) to your build process.
Focus on Important Issues: Don't overwhelm teams with thousands of warnings. Configure the tools to highlight only the most critical problems first.
Track Your Progress: Measure how long it takes to fix a vulnerability after it's found. This shows you if your process is improving.
Encourage Teamwork: Have security experts and developers work together on solutions. This builds a shared culture of security.

Conclusion: The New Essential

Security is not a separate phase anymore. It is a core part of building software, like performance or usability. DevSecOps is how you make that happen.

The question is no longer if you can afford to do DevSecOps, but if you can afford not to. The risk of ignoring it is too high. Building security in from the start creates software that is faster, stronger, and secure—protecting your customers and your business.

Follow Me for More Security Tips.

Building an Automated Event-Driven File Processing System in Azure (No Code Required)

Ezekiel Umesi — Thu, 11 Sep 2025 20:43:11 +0000

Managing file uploads and post-processing workflows often requires custom scripts, manual oversight, and complex pipelines. But with Microsoft Azure, you can build a fully automated, event-driven file processing system—all through the Azure Portal. No command-line tools, no coding beyond minimal setup.

This guide walks you step by step through creating a seamless workflow where uploading a file automatically triggers processing, archiving, and cleanup actions.

🚀 What You’ll Build

Workflow Overview:

File Upload → Blob Storage → Event Grid → Logic App → App Service → Automation Account

Here’s how it works in practice:

A user uploads a file to Azure Blob Storage.
Event Grid detects the upload and fires an event.
Logic App orchestrates the workflow.
App Service processes the file with your business logic.
Automation Account archives and cleans up processed files.

This architecture scales automatically, has built-in monitoring, and charges only for what you use.

✅ Prerequisites

Before you start, ensure you have:

An active Azure subscription
Contributor access to create resources
A modern browser (Edge, Chrome, or Firefox)
A test file (any text, image, or document)

Part 1: Foundation Setup

1. Create a Resource Group

In the Azure Portal, create a new Resource Group:
- Name: rg-workflow-demo
- Region: Your closest Azure region

This keeps all components organized.

2. Create a Storage Account

The storage account stores uploaded files and emits events when new files arrive.

Name: stworkflowdemo123456 (use random numbers for uniqueness)
Redundancy: LRS
Secure transfer: Enabled
Public access: Private

Then, create a container inside it:

Name: input-files
Public Access: Private

Part 2: Build the Processing Engine

1. App Service Plan

Create an App Service Plan to host your file processing logic.

Name: asp-workflow-demo
OS: Linux
Pricing Tier: B1 Basic

2. Web App

Create a Web App on that plan.

Name: app-workflow-processor-123456
Runtime: Node.js 18 LTS

3. Deploy Processing Logic

Through Kudu (Advanced Tools) or App Service Editor, create two files:

package.json

{
  "name": "azure-file-processor",
  "version": "1.0.0",
  "main": "app.js",
  "scripts": { "start": "node app.js" },
  "dependencies": {
    "express": "^4.18.2",
    "@azure/storage-blob": "^12.17.0"
  }
}

app.js → contains your processing logic (e.g., reading blob metadata).

Run npm install in the console.

Add an App Setting for your storage connection string:

Key: STORAGE_CONNECTION_STRING
Value: [Your storage connection string]

Part 3: Orchestrate with Logic Apps

The Logic App coordinates the workflow.

Create a Logic App (Consumption).
Add a trigger: When an HTTP request is received.
Parse the Event Grid JSON payload.
Extract file details with a Compose action.
Call the App Service API using an HTTP action.
Add a Condition to check if processing succeeded.

Part 4: Post-Processing Automation

Create an Automation Account for archiving and cleanup.

Runbook: Archive Files

Create a PowerShell Runbook that:

Connects via Managed Identity
Creates an processed-files container if missing
Copies the file into it with a timestamped name

Example archive file: 20250911_213000_myfile.txt

Part 5: Security & Permissions

Logic App → Storage Account: Assign Storage Blob Data Reader
Automation Account → Storage Account: Assign Storage Blob Data Contributor
Logic App → Automation Account: Assign Automation Contributor

Enable System-assigned Managed Identity on both Logic App and Automation Account.

Part 6: Event Grid Integration

Finally, wire up the trigger:

Event Source: Blob Created in input-files
Event Schema: Event Grid Schema
Endpoint: Logic App HTTP POST URL

Part 7: Test the Workflow

Upload a test file to input-files.
Watch Event Grid trigger the Logic App.
Check App Service Log Stream for processing logs.
Verify the Automation Runbook created an archived copy in processed-files.

Expected Outcome:

File uploaded → automatically processed → archived with timestamp.

🔎 Troubleshooting Tips

Logic App not triggering? Check event subscription status.
App Service errors? Review Log Stream and verify connection strings.
Automation failures? Confirm role assignments & module imports.
Permission errors? Wait 5–10 minutes after role assignment.

💡 Benefits of This Architecture

No Coding Required → All via Azure Portal
Fully Automated → Zero manual intervention
Scalable → Handles single or bulk uploads
Secure → Managed identities, no secrets
Cost-Effective → Pay-per-use pricing
Monitored → Full visibility in Azure Portal

💰 Cost Considerations (100 files/month)

Logic Apps: ~\$5–15
App Service B1: ~\$13
Storage: ~\$2–10
Automation: First 500 min free
Event Grid: First 100K ops free

👉 Use Free App Service tier during development.

Next Steps: Go Beyond the Portal

Once comfortable with the portal, explore Infrastructure as Code with:

Azure CLI → Automate deployments
ARM/Bicep → Template-driven provisioning
Terraform → Cloud-agnostic automation
CI/CD Pipelines → Continuous deployment

Example command:

az storage blob upload --account-name stworkflowdemo123456 \
--container-name input-files \
--name test.txt --file ./test.txt

🎯 Conclusion

With just the Azure Portal, you’ve built a production-ready, event-driven file processing pipeline. From file upload to automated archiving, every step happens seamlessly without manual effort.

This foundation is perfect for learning, prototyping, and scaling into enterprise-grade solutions with Infrastructure as Code.

Your Azure workflow is now ready to handle real-world file processing scenarios—securely, efficiently, and automatically.

How to Build a Simple Node.js Server from Scratch — A Step-by-Step Guide

Ezekiel Umesi — Sun, 20 Jul 2025 14:23:46 +0000

Are you ready to create your first backend project with Node.js? In this post, you’ll learn how to build a basic Node.js HTTP server that handles different routes and sends back responses — all using core Node modules (no frameworks like Express yet!).

Let’s break it down step by step and explain exactly what’s happening behind the scenes. 💡

🛠️ Step 1: Set Up Your Project

Before writing any code, we need a place to put it:

mkdir my-nodejs-server
cd my-nodejs-server
npm init -y

This creates a new project folder and initializes it with a default package.json file.

✨ Step 2: Create Your Server File

Now let’s create the file that will run your server:

touch server.js

Open server.js in your code editor (VS Code, Vim, or anything else you like).

💻 Step 3: Write Your First HTTP Server

🔹 1. Import the HTTP Module

const http = require('http');

👉 This brings in Node.js’s built-in http module, which lets us create web servers. No need to install anything extra!

🔹 2. Create the Server

const server = http.createServer((req, res) => {
    // Request handler logic goes here
});

req: The request object (contains details about the request — like the URL and method).
res: The response object (we’ll use this to send data back to the browser).

🔹 3. Handle Routes

Now let’s respond based on the URL path requested:

const server = http.createServer((req, res) => {
    if (req.url === '/') {
        res.statusCode = 200;
        res.setHeader('Content-Type', 'text/plain');
        res.end('Hello, World! 🌍\n');
    } else if (req.url === '/about') {
        res.statusCode = 200;
        res.setHeader('Content-Type', 'text/plain');
        res.end('About Us 📖\n');
    } else {
        res.statusCode = 404;
        res.setHeader('Content-Type', 'text/plain');
        res.end('Page Not Found 🚨\n');
    }
});

What’s happening here?

We inspect req.url to determine which page was requested.
We respond with appropriate text for /, /about, or anything else (which returns a 404).

🔹 4. Start Listening for Requests

Finally, let’s make our server start listening:

const port = 3000;
const hostname = '127.0.0.1';

server.listen(port, hostname, () => {
    console.log(`Server running at http://${hostname}:${port}/ 🎉`);
});

✅ 127.0.0.1 is your localhost IP.
✅ 3000 is the port where the server will run.
✅ The callback confirms when the server is up.

📜 Full Code: `server.js`

const http = require('http');

const server = http.createServer((req, res) => {
    if (req.url === '/') {
        res.statusCode = 200;
        res.setHeader('Content-Type', 'text/plain');
        res.end('Hello, World! 🌍\n');
    } else if (req.url === '/about') {
        res.statusCode = 200;
        res.setHeader('Content-Type', 'text/plain');
        res.end('About Us 📖\n');
    } else {
        res.statusCode = 404;
        res.setHeader('Content-Type', 'text/plain');
        res.end('Page Not Found 🚨\n');
    }
});

const port = 3000;
const hostname = '127.0.0.1';

server.listen(port, hostname, () => {
    console.log(`Server running at http://${hostname}:${port}/ 🎉`);
});

⚡ Step 4: Run and Test Your Server

Start the server:

node server.js

Now open your browser and visit:

✅ http://127.0.0.1:3000/ → Should show Hello, World! 🌍
✅ http://127.0.0.1:3000/about → Should show About Us 📖
❌ http://127.0.0.1:3000/contact → Should show Page Not Found 🚨

To stop the server, hit Ctrl + C in your terminal.

🧠 How It All Works Behind the Scenes

Here’s a simplified flow:

The browser sends a GET request to your server.
Node’s http module captures it.
Your code checks the requested route (req.url).
A response is built and returned with res.end().
The browser receives and displays it.

🛤️ Key Takeaways

Concept	Description
`req.url`	The path the client is requesting (`/`, `/about`, etc.)
`res.statusCode`	Sets HTTP status like 200 (OK) or 404 (Not Found)
`res.setHeader()`	Tells the browser what type of content it’s getting
`res.end()`	Ends the response and sends it to the client

🎉 Final Words

You just built a fully functioning Node.js HTTP server with zero dependencies. 🎉

It’s a simple project — but a foundational one. From here, you can build more complex backend systems and eventually integrate databases, authentication, REST APIs, and beyond.

Happy coding! 💻✨

Building and Deploying a MEAN Stack Application on Azure

Ezekiel Umesi — Sun, 20 Jul 2025 13:46:07 +0000

As full-stack development continues to evolve, the MEAN stack has emerged as one of the most popular choices for building modern, scalable web applications. This blog post will walk you through a hands-on guide—from understanding the MEAN stack to deploying it on cloud platforms like Azure Virtual Machines.

📦 What is the MEAN Stack?

The MEAN stack is a powerful, JavaScript-based framework that allows developers to build end-to-end web applications using a single language across the entire stack.

Core Components

MongoDB: A NoSQL database for storing data in JSON-like documents. It’s perfect for handling unstructured or semi-structured data.
Express.js: A fast and minimalist backend framework that simplifies building RESTful APIs.
Angular: A frontend framework for building single-page applications (SPAs), providing dynamic and rich user interfaces.
Node.js: A runtime environment for executing JavaScript server-side, enabling non-blocking, event-driven development.

Why Use MEAN?

JavaScript Everywhere: One language across the frontend, backend, and database layer.
Open Source: Strong community support with free-to-use tools.
Scalable: Suitable for both small projects and enterprise-scale applications.
Real-Time Ready: Great for chat apps, live feeds, and collaborative tools.

☁️ Deploying MEAN Stack on Azure or AWS

Let’s break down the deployment process into manageable steps.

🛠 Step 1: Provision a Virtual Machine

🔷 Azure

Log in to the Azure Portal.
Navigate to Virtual Machines > Create.
Choose Ubuntu 22.04 LTS as the OS.
Select a size like B1s for testing.
Allow inbound ports: SSH (22), HTTP (80), and HTTPS (443).
Connect via SSH:

ssh azureuser@<public-ip>

⚙️ Step 2: Install MEAN Stack Components

✅ Update System & Install Dependencies

sudo apt update && sudo apt upgrade -y
sudo apt install -y git curl

🍃 Install MongoDB

wget -qO - https://www.mongodb.org/static/pgp/server-6.0.asc | sudo apt-key add -
echo "deb [ arch=amd64,arm64 ] https://repo.mongodb.org/apt/ubuntu jammy/mongodb-org/6.0 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-6.0.list
sudo apt update
sudo apt install -y mongodb-org
sudo systemctl start mongod
sudo systemctl enable mongod

🟩 Install Node.js and npm

curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash -
sudo apt install -y nodejs

🧱 Step 3: Set Up the Express Backend

mkdir mean-app && cd mean-app
npm init -y
npm install express mongoose cors

Create server.js:

const express = require('express');
const mongoose = require('mongoose');
const cors = require('cors');
const app = express();
const PORT = process.env.PORT || 3000;

app.use(express.json());
app.use(cors());

mongoose.connect('mongodb://localhost:27017/mean-db')
  .then(() => console.log('Connected to MongoDB'))
  .catch(err => console.error('MongoDB connection error:', err));

app.get('/', (req, res) => res.send('MEAN Stack Backend Running!'));

app.listen(PORT, () => console.log(`Server listening on port ${PORT}`));

Run with PM2:

sudo npm install -g pm2
pm2 start server.js
pm2 save
pm2 startup

🧑‍🎨 Step 4: Deploy Angular Frontend

Install Angular CLI:

sudo npm install -g @angular/cli

Create and build the Angular project:

ng new frontend --defaults
cd frontend
ng build --configuration production

Move build output to backend public directory:

cp -r dist/frontend/* ../mean-app/public/

Update server.js to serve static files:

app.use(express.static('public'));

For this assignment, I chose not to use Nginx since I didn't have an available domain name.

View the website on your browser here

http:<public_ip>:3000

✅ Conclusion

The MEAN stack is a great choice for modern full-stack applications thanks to its unified JavaScript ecosystem, flexibility, and scalability. Deploying your MEAN stack app on a cloud VM (like Azure or AWS) gives you full control over your infrastructure and allows you to scale as needed.

Whether you're building a personal project or launching a production-grade system, mastering this deployment workflow will give you the confidence and skills to deliver high-performing web apps.

How to Secure Azure Storage with Customer-Managed Keys and Managed Identities

Ezekiel Umesi — Thu, 03 Jul 2025 21:32:02 +0000

When building cloud-native applications, securing your storage resources is a top priority. Azure provides powerful tools like Managed Identities, Key Vault, Customer-Managed Keys (CMKs), and Immutable Storage to help you do just that.

In this guide, we’ll walk through how to:

Create a storage account with infrastructure encryption
Set up a managed identity and assign access
Create a Key Vault with customer-managed keys
Configure your storage account to use those keys
Set up immutable blob storage and encryption scopes

✅ Step 1: Create the Storage Account

In the Azure Portal, search for Storage accounts and click + Create.
Create a new Resource Group, name it accordingly.
Provide a unique name for your storage account.
Navigate to the Encryption tab.
Enable the checkbox for Infrastructure encryption.

⚠️ This cannot be changed after creation.

Click Review + Create, then Create the storage account.

✅ Step 2: Create a User-Assigned Managed Identity

In the Azure Portal, search for Managed identities and click + Create.
Choose the same Resource Group.
Name your managed identity (e.g., ezekielmanagedidentity).
Click Review + create, then Create.

✅ Step 3: Assign Storage Permissions to the Managed Identity

Go to your Storage Account > Access Control (IAM).
Click + Add role assignment.
Select Storage Blob Data Reader.
On the Members tab:

Choose Managed identity
Select User-assigned managed identity
Pick the identity you created earlier
1. Click Review + assign (twice to confirm).

✅ Step 4: Give Yourself Key Vault Administrator Access

Go to Resource Group > Access Control (IAM).
Click + Add role assignment.
Choose the Key Vault Administrator role.
Select User, group, or service principal.
Pick your user account from the list.
Click Review + assign (twice).

✅ Step 5: Create a Key Vault and a Key

In the Azure Portal, search for Key vaults and click + Create.
Use your existing Resource Group and give the vault a unique name.
On the Access Configuration tab, ensure Azure role-based access control (recommended) is selected.
Click Review + create, then Create.
After deployment, click Go to resource.
Confirm that Soft-delete and Purge protection are enabled.
Under Keys, click + Generate/Import.
Provide a name, leave other settings as default, and click Create.

✅ Step 6: Grant Encryption Role to the Managed Identity

Go to your Resource Group > Access Control (IAM).
Click + Add role assignment.
Select Key Vault Crypto Service Encryption User.
Choose Managed identity, then select your user-assigned identity.
Click Review + assign (twice).

✅ Step 7: Configure Customer-Managed Key on the Storage Account

Go back to your Storage Account > Encryption.
Switch to Customer-managed keys.
Select your Key Vault and the key you created earlier.
Set Identity type to User-assigned.
Select your managed identity and click Add.
Click Save.

🔁 If you get an error, wait a few minutes to let permissions propagate, then retry.

✅ Step 8: Configure Immutable Blob Storage

Navigate to your Storage Account > Containers.
Click + Container, name it hold, and create it with default settings.
Upload a test file to the container.
Go to Settings > Access policy.
Under Immutable blob storage, click + Add policy.

Policy type: Time-based retention
Retention period: 5 days
1. Save the changes.

🧪 Try deleting the file. You should get a deletion failed error due to the policy.

✅ Step 9: Create an Encryption Scope with Infrastructure Encryption

Go back to your Storage Account > Encryption > Encryption scopes tab.
Click + Add.
Name your scope (e.g., myezekielwncryptionscope).
Set:

Encryption type: Microsoft-managed keys
Infrastructure encryption: Enabled
1. Click Create.

✅ Step 10: Use the Encryption Scope in a New Container

Return to your Storage Account > Containers.
Click + Container.
Provide a Name and set Public access level.
Under Advanced, choose the Encryption scope you created.
Create the container.

Setting Up Azure File Share with Snapshots and Secure Access

Ezekiel Umesi — Thu, 03 Jul 2025 07:52:07 +0000

Azure Files is a great solution when you need shared file storage in the cloud — just like a network file share, but hosted and managed by Azure. In this guide, I’ll walk you through how to:

Create a Premium Storage Account for Azure Files
Set up a File Share with directories and uploaded files
Enable Snapshots for recovery
Restrict access using Virtual Networks

This is a perfect setup for teams like Finance, who need secure, high-performance, and recoverable shared storage.

📦 Step 1: Create the Azure Storage Account

Go to the Azure Portal.
Search for and select Storage accounts.
Click + Create.
Create a new resource group (e.g., storage-rg).
Enter a unique name for the storage account (e.g., ezekielstorageaccount).
Set:

Performance: Premium
Premium account type: File shares
Redundancy: Zone-redundant storage (ZRS)
1. Click Review + Create, then Create.
2. After deployment, click Go to resource.

✅ Why Premium? Premium storage gives low-latency and high-throughput — perfect for file sharing.

📁 Step 2: Create a File Share and Add Directory

In your storage account, go to File shares under Data storage.
Click + File share.
Enter a name like ezekiel-file-share and click Create.
Once created, click the file share, then + Add directory.
Name the directory finance.

💡 You can organize your file shares using folders, just like on a traditional file server.

⬆️ Step 3: Upload a File

Open the finance directory.
Click Upload and choose any test file (e.g., a .txt or .pdf).
Upload the file.

Now, your file share has a folder and a test file — ready to be backed up and secured.

🕒 Step 4: Enable and Test Snapshots

Snapshots in Azure Files help you restore previous versions of files or recover deleted files.

Go to the file share → select the Snapshots tab under Operations.
Click + Add snapshot → click OK.
Select the snapshot and ensure your finance folder and file are included.

🧪 Test Restoring a File from Snapshot

Go back to your file share → open the finance folder.
Delete the uploaded file (click the file → Delete → Yes).
Return to the Snapshots tab → open the snapshot.
Navigate to the deleted file → click Restore.
Give it a new name (e.g., my-upload) and restore.
Go back to your file share and confirm the restored file is there.

📌 Snapshots are point-in-time copies — great for protecting against accidental deletion.

🔐 Step 5: Restrict Access Using Virtual Network

Let’s now restrict access so that only users within a specific virtual network (VNet) can connect to this storage account.

🌐 Create a Virtual Network

In the portal, search for Virtual networks → click + Create.
Use your storage account’s resource group.
Name it something like storage-vnet.
Click Review + Create, then Create.

🔁 Add a Service Endpoint

After deployment, go to your VNet → Subnets.
Click on the default subnet.
Under Service endpoints, select Microsoft.Storage.
Click Save.

This allows the VNet to securely connect to Azure Storage.

🔒 Limit Access in the Storage Account

Go back to your storage account → go to Networking under Security + networking.
Set Public network access to: ➤ Enabled from selected virtual networks and IP addresses
In the Virtual networks section, click Add existing virtual network.
Choose storage-vnet and its default subnet → click Add.
Save your changes.

🔍 Step 6: Test the Security

Try accessing the file share from the Storage browser in the portal. You should see an error like:

❌ “Not authorized to perform this operation.”

This confirms your restriction is working — access is allowed only from inside your VNet.

✅ Summary

Here’s what we achieved:

Feature	Configuration
Storage Type	Premium, ZRS
File Share	`corporate-share` with `finance` folder
Upload File	Test file uploaded
Snapshots	Enabled and tested file recovery
VNet Restriction	Access allowed only from `finance-vnet`
File Recovery	Manual restore from snapshot tested

Azure Files is powerful when you want cloud-based shared folders with backup, access control, and high availability — all without managing servers. This setup is a great starting point for securely storing and managing corporate documents.

How to Set Up Azure Virtual Machines in Multiple Availability Zones (Manual Failover Scenario)

Ezekiel Umesi — Mon, 30 Jun 2025 12:19:03 +0000

When running critical applications in the cloud, availability matters. Azure provides Availability Zones (AZs) to help protect your apps from data center failures. In this guide, I’ll walk you through setting up Virtual Machines (VMs) in different zones — allowing for manual failover if one zone goes down.

This setup is great for learning how high availability and disaster recovery work at the infrastructure level.

🌍 What Are Availability Zones?

Availability Zones are physically separate locations within an Azure region. Each zone has its own:

Power
Cooling
Networking

Deploying VMs across zones ensures that even if one zone goes down, your app can recover from another — though in manual failover, you must redirect traffic or services yourself.

🧰 What You'll Do in This Guide

Deploy 2 Virtual Machines across different AZs using VMSS
Test the setup

🖥 Step 1: Create Virtual Machines in Different AZs

VM 1 (Primary)

Go to Virtual Machines → + Create → Virtual Machine Scale Set
Name: win11vm-1
Region: Same as your VNet
Availability Zone: Zone 1
Choose image (e.g., Win11)
Size: Standard B2s (for demo purposes)
Add to the failover-vnet network
Allow RDP/SSH depending on OS
Click Review + Create

This Virtual Machine Scale Set gives you one VM in Zone 1 and another in Zone 2.

🧪 Step 3: Test Both VMs

Virtual Machine 1

Virtual Machine 2

✅ Summary

Feature	Description
Region	East US (or any region with AZs)
Manual Failover	No Load Balancer present

📝 Final Thoughts

Using Azure Availability Zones gives your infrastructure resilience against unexpected failures. In this lab-style setup, we used manual failover — a realistic way to understand what happens when one part of your system becomes unavailable.

How to Store Private Files in Azure Blob Storage

Ezekiel Umesi — Sun, 29 Jun 2025 23:25:45 +0000

How to Store Private Files in Azure Blob Storage

Azure Blob Storage is a great way to host both public website content and private company files. In this post, I’ll guide you through:

Adding safety features like soft delete and versioning
Creating a private storage account for sensitive documents
Giving temporary access using SAS (Shared Access Signatures)
Using lifecycle rules to manage storage costs
Setting up replication to back up files from one storage account to another

Let’s dive in.

☁️ Part 1: Set Up a Public Storage Account

🔧 Step 1: Create the Storage Account

Log in to the Azure Portal.
Search for "Storage accounts" and click + Create.
Create a new resource group (e.g., storage-rg).
Name your account something like privatewebsitemyezekiel (the name must be globally unique).
Click Review + Create, then Create.

🔐 Part 2: Store Internal Documents in a Private Container

🔧 Step 1: Create the Private Storage Account

Create another storage account (e.g., privatewebsitemyezekiel) in the same resource group.
Click Review + Create, then Create.

🌐 Step 2: Enable Geo-Redundant Storage (GRS Only)

In the storage account, go to Redundancy.
Select Geo-redundant storage (GRS) — no read access needed.
Save the setting.

📁 Step 3: Create a Private Container

Go to Containers → click + Container.
Name it private.
Set Public access level to Private (no anonymous access).
Click Create.

🚫 Step 4: Test That the File Is Not Public

Upload a small file.
Copy the Blob URL and try to open it in a browser — it should not open.

🔐 Step 5: Grant Temporary Access with SAS

Click on the uploaded file → go to the Generate SAS tab.
Grant Read permission.
Set an expiry of 24 hours.
Click Generate SAS token and URL.
Open the URL in a browser to test.

✅ The file should now load only with this link.

🧊 Step 6: Use Lifecycle Rules to Save Costs

Go to Lifecycle management.
Click Add rule.
Name it movetocool.
Apply to all blobs → set rule to "Last modified more than 30 days" → Move to cool tier.
Save the rule.

🔁 Step 7: Backup Public Files with Replication

In the private storage account, create a new container named backup.
Go to the public storage account → Object replication.
Create a replication rule:

Destination account: private storage
Source container: public
Destination container: backup
1. Upload a file to public, and it will appear in backup after a few minutes.

✅ Summary

Here’s what we’ve accomplished:

Feature	Public Account	Private Account
High Availability	RA-GRS	GRS
Anonymous Access	Enabled	Disabled
Soft Delete	Enabled (21 days)	Optional
Blob Versioning	Enabled	Optional
SAS Access	Not needed	Used for secure sharing
Lifecycle Management	Move to cool after 30 days	Same
Replication	From public to backup	As destination only

This setup ensures that public content is easily accessible and private files are secure, while still keeping your storage cost-effective and recoverable.

How to Set Up a High-Availability Azure Storage Account for a Public Website

Ezekiel Umesi — Sun, 29 Jun 2025 21:11:59 +0000

If you’re hosting static content like images, website files, or documents, Azure Storage is a reliable, cost-effective solution. In this guide, I’ll show you how to:

Create a high-availability Azure storage account
Enable public blob access for website users
Configure soft delete and versioning to protect your files

Let’s get started.

🛠 Step 1: Create the Storage Account

Open the Azure Portal.
In the search bar, type and select “Storage accounts”.
Click + Create.
For Resource group, click Create new, enter a name like storage-rg, and click OK.
Name the storage account publicwebsitemyezekiel (add random characters to make it globally unique).
Keep other settings as default.
Click Review + Create, then Create.

🌐 Step 2: Enable Read-Access Geo-Redundant Storage (RA-GRS)

After deployment, go to the newly created storage account.

In the Data management section, click Redundancy.
Select Read-access geo-redundant storage (RA-GRS).
Review the Primary and Secondary region info.

🔓 Step 3: Allow Anonymous Access

To make your content accessible to everyone:

In the Settings section, select Configuration.
Set Allow blob anonymous access to Enabled.
Click Save.

📁 Step 4: Create a Container for Website Files

Go to Containers under Data storage.
Click + Container.
Name it public.
Click Create.
Select the new public container.
On the Overview tab, click Change access level.
Set it to Blob (anonymous read access for blobs only), then OK.

⬆️ Step 5: Upload and Test a File

Inside the public container, click Upload.
Select any small file (like an image or text file) from your computer.
Click Upload, then Refresh to see your file.
Click on the file → Overview tab → copy the URL.
Paste the URL in a browser tab.

✅ Image files will display; others (e.g. .txt, .pdf) will download.

♻️ Step 6: Enable Soft Delete (21 Days)

This helps recover deleted files.

Go to the storage account’s Overview tab.
Under Blob service, click Soft delete.
Enable the setting.
Set Keep deleted blobs for to 21 days.
Click Save.

🧪 Step 7: Test Soft Delete and Restore

Return to your container, select the file, and click Delete → Confirm.
On the container page, toggle Show deleted blobs.
Find your deleted file → Click ... → Undelete.
Refresh the page to confirm it's restored.

🔄 Step 8: Enable Blob Versioning

To keep a history of changes to files:

Go back to the storage account Overview tab.
Under Blob service, click Versioning.
Enable Versioning for blobs.
Click Save.

⏪ Step 9: Test Blob Versioning

Upload a new version of the same file (same name) to overwrite it.
Toggle Show deleted blobs — you’ll see the previous version listed.

✅ Final Thoughts

By following this guide, you’ve successfully:

Set up a highly available storage account with RA-GRS
Enabled anonymous blob access for public use
Configured soft delete to prevent data loss
Turned on versioning to track file history

This setup is perfect for hosting static website content, images, downloads, and more — with built-in protection and global availability.

How I Created a Linux VM on Azure and Installed NGINX

Ezekiel Umesi — Sun, 29 Jun 2025 13:23:35 +0000

As part of my ongoing cloud computing training, I was tasked with deploying a Linux virtual machine (VM) on Microsoft Azure and installing NGINX web server on it. Below is a breakdown of the entire process — from creating the VM to accessing the NGINX welcome page.

Step 1: Log into the Azure Portal

I started by logging into https://portal.azure.com using my Microsoft account.

Step 2: Search for “Virtual Machines”

In the Azure Portal, I used the search bar at the top to search for “Virtual Machines” and selected it from the dropdown menu.

Step 3: Create a Linux VM

I clicked the “+ Create” button and selected “Azure virtual machine.”

In the Basics tab, I entered the following configuration:

Subscription: My current Azure subscription
Resource Group: Selected an existing one or created a new one
Virtual Machine Name: linux-nginx-vm
Region: Chose the closest Azure region
Image: Selected Ubuntu 22.04 LTS
Size: Chose a lightweight option like Standard_B1s
Authentication type: Selected Password
Username and Password: Set my SSH login credentials

⚠️ Make sure to allow port 22 (SSH) under the Inbound port rules so you can connect to the VM.

Step 4: Review + Create

After confirming the settings, I clicked “Review + Create”, waited for validation to complete, and then clicked “Create.” Azure started provisioning the VM.

Step 5: Connect to the Linux VM via SSH

Once the VM was deployed, I connected using SSH.

I copied the public IP address from the VM overview and ran the following command from my terminal:

ssh <username>@<public-ip>

It prompted for my password, and then I was successfully logged into the Linux VM.

Step 6: Install NGINX on the Linux VM

After logging in, I ran the following commands to install NGINX:

sudo apt update
sudo apt install nginx -y

Once installed, I confirmed the status of NGINX:

sudo systemctl status nginx

The output showed that NGINX was active (running).

Step 7: View the NGINX Welcome Page

To access the default NGINX web page, I opened a browser and visited:

http://<public-ip>

The NGINX welcome page appeared, which means the installation was successful.

Summary

Step	Description
1	Logged into Azure Portal
2	Created a new Ubuntu VM
3	Connected via SSH
4	Installed NGINX
5	Verified using the public IP in a browser

Lessons Learned

How to provision a Linux VM in Azure
How to connect to a Linux VM using SSH
How to install and start NGINX using basic terminal commands
The role of inbound port rules in exposing services like NGINX

How I Deployed a Windows 11 Virtual Machine on Azure

Ezekiel Umesi — Sun, 29 Jun 2025 12:51:24 +0000

As part of my cloud computing class, we were tasked with creating and deploying a Windows 11 virtual machine (VM) using the Azure portal. This guide walks you through the steps I followed to get it done — no coding involved, just pure cloud interface configuration!

Step 1: Login to Azure Portal

I started by visiting the Azure Portal at https://portal.azure.com and logging in with my Microsoft account. This is where all Azure resources are created and managed.

Step 2: Search for “Virtual Machines”

On the Azure dashboard, I used the search bar at the top and typed “Virtual Machines.” I clicked on the Virtual Machines option that appeared in the search results.

Step 3: Create a New VM

I clicked the “+ Create” button and selected “Azure virtual machine”. This opened a setup wizard to configure the virtual machine.

📸 [Insert screenshot of the Create VM form]

Step 4: Configure the Basic Settings

Here's what I entered in the Basics tab:

Subscription: "Subscription 1"
Resource Group: "cloud101-rg"
Virtual Machine Name: I used win11-vm
Region: I picked a region closest to me, like East US
Image: I selected Windows 11 Pro, version 22H2 - Gen2
Size: I went with a VM size that meets the minimum requirements for Windows 11 (e.g., Standard_D2s_v3)
Administrator Account:
- Username: A name I could remember
- Password: A strong, secure password

⚠️ Note: Windows 11 requires TPM and Secure Boot — that’s why only Gen2 VM images are supported.

Step 5: Configure Networking

I left most settings on default, but made sure that:

Public IP was enabled so I could RDP into the machine
Port 3389 (for Remote Desktop) was open

Step 6: Review + Create

After going through all the required tabs (leaving the rest at default values), I clicked on “Review + Create”. Once Azure validated my settings, I clicked “Create.”

Azure began provisioning the VM. After a few minutes, the Windows 11 VM was ready to use.

Step 7: Connect to the Windows 11 VM

Once the deployment was complete, I:

Navigated to the VM page
Clicked on Connect > RDP
Downloaded the RDP file
Opened the file and logged in using the username and password I created earlier

📸

What I Learned

How to select and configure a Windows 11 image in Azure
The importance of Gen2 VM requirements (TPM, Secure Boot)
How to expose the correct ports to connect to a VM securely
How Azure handles provisioning, networking, and remote access

Summary of Key Steps

Step	Description
1	Logged into Azure Portal
2	Searched for Virtual Machines
3	Clicked Create and chose Windows 11
4	Configured basic settings
5	Enabled networking with RDP access
6	Reviewed and created the VM
7	Connected using Remote Desktop

DEV Community: Ezekiel Umesi

The Dangerous Comfort of the Checkbox: Why Compliance is Not Security

Why Saying "Compliance = Security" is Wrong and Dangerous

1. Compliance Looks Backward. Threats Come from the Future.

2. Compliance is the Minimum, Not the Goal

3. The Checkbox Mindset vs. The Security Mindset

4. Your Audit Scope vs. Your Real Attack Surface

How to Build a Truly Secure Program

Conclusion: The Map and the Territory

Shifting Security Left: Why DevSecOps is Not Optional Anymore

What Does "Shifting Left" Mean?

Why You Must Use DevSecOps Now: The Real Reasons

How to Start: A Practical Approach

Conclusion: The New Essential

Building an Automated Event-Driven File Processing System in Azure (No Code Required)

🚀 What You’ll Build

✅ Prerequisites

Part 1: Foundation Setup

1. Create a Resource Group

2. Create a Storage Account

Part 2: Build the Processing Engine

1. App Service Plan

2. Web App

3. Deploy Processing Logic

Part 3: Orchestrate with Logic Apps

Part 4: Post-Processing Automation

Runbook: Archive Files

Part 5: Security & Permissions

Part 6: Event Grid Integration

Part 7: Test the Workflow

🔎 Troubleshooting Tips

💡 Benefits of This Architecture

💰 Cost Considerations (100 files/month)

Next Steps: Go Beyond the Portal

🎯 Conclusion

How to Build a Simple Node.js Server from Scratch — A Step-by-Step Guide

🛠️ Step 1: Set Up Your Project

✨ Step 2: Create Your Server File

💻 Step 3: Write Your First HTTP Server

🔹 1. Import the HTTP Module

🔹 2. Create the Server

🔹 3. Handle Routes

🔹 4. Start Listening for Requests

📜 Full Code: server.js

⚡ Step 4: Run and Test Your Server

🧠 How It All Works Behind the Scenes

🛤️ Key Takeaways

🎉 Final Words

Building and Deploying a MEAN Stack Application on Azure

📦 What is the MEAN Stack?

Core Components

Why Use MEAN?

☁️ Deploying MEAN Stack on Azure or AWS

🛠 Step 1: Provision a Virtual Machine

🔷 Azure

⚙️ Step 2: Install MEAN Stack Components

✅ Update System & Install Dependencies

🍃 Install MongoDB

🟩 Install Node.js and npm

🧱 Step 3: Set Up the Express Backend

🧑‍🎨 Step 4: Deploy Angular Frontend

✅ Conclusion

How to Secure Azure Storage with Customer-Managed Keys and Managed Identities

✅ Step 1: Create the Storage Account

✅ Step 2: Create a User-Assigned Managed Identity

✅ Step 3: Assign Storage Permissions to the Managed Identity

✅ Step 4: Give Yourself Key Vault Administrator Access

✅ Step 5: Create a Key Vault and a Key

✅ Step 6: Grant Encryption Role to the Managed Identity

✅ Step 7: Configure Customer-Managed Key on the Storage Account

✅ Step 8: Configure Immutable Blob Storage

✅ Step 9: Create an Encryption Scope with Infrastructure Encryption

✅ Step 10: Use the Encryption Scope in a New Container

Setting Up Azure File Share with Snapshots and Secure Access

📦 Step 1: Create the Azure Storage Account

📁 Step 2: Create a File Share and Add Directory

⬆️ Step 3: Upload a File

🕒 Step 4: Enable and Test Snapshots

🧪 Test Restoring a File from Snapshot

🔐 Step 5: Restrict Access Using Virtual Network

📜 Full Code: `server.js`