5 ms·

At this point I have close to a decade of working with Azure and AWS/GCP and I can confidently say Azure is the worst when it comes to security, objectively. P

At this point I have close to a decade of working with Azure and AWS/GCP and I can confidently say Azure is the worst when it comes to security, objectively. Performance, "I don't like the portal", service and capacity availability, and such complaints are somewhat subjective or fixable but I deeply believe Microsoft is the most insecure of the cloud giants on a measurable level. Anyone that is serious about security should just avoid Microsoft, this has honestly been the case since the early '00s at the least.

Mossy9 2y ago
As someone who is greatly motivated to moving off Azure (to onprem, not to another cloud), do you know of any good collection of Azure security issues I could use as 'ammunition'? Would be greatly appreciated! UPD: note to self - this seems like a good resource https://www.cloudvulndb.org/results https://www.cloudvulndb.org/results
- redrove 2y ago
  I have some notes somewhere but unfortunately they don't have citations, these are just some of the vulns they've had in the last couple years: • Storm-0558 Breach (2023): Chinese hackers exploited a leaked signing key from a crash dump to access U.S. government emails, affecting 60,000+ State Department communications • Azure OpenAI Service Exploitation (2024): Hackers bypassed AI guardrails using stolen credentials to generate illicit content, leading to Microsoft lawsuits against developers in Iran, UK, and Vietnam • CVE-2025-21415 (CVSS 9.9): Spoofing vulnerability in Azure AI Face Service allowed authentication bypass and privilege escalation • CVE-2023-36052: Azure CLI logging flaw exposed plaintext credentials in CI/CD pipelines, risking sensitive data leakage • Azurescape (2022): Container escape vulnerability enabled cross-tenant access in Azure Container Instances, discovered by Palo Alto Networks • ChaosDB (2022): Wiz researchers exploited CosmosDB’s Jupyter Notebook integration to access thousands of customer databases including Fortune 500 companies • Executive Account Takeover Campaign (2024): Phishing campaign compromised 500+ executive accounts via Azure collaboration tools with MFA manipulation If your company or workplace is considering migrating from cloud to on-prem or from one cloud to another, I do this professionally btw, feel free to reach out at this temporary email and we can chat: pale.pearl2178 at fastmail.com (to prevent my real email being scraped from HN).
  - Mossy9 2y ago
    Great, thanks! For me it's just a distant dream now, but I bet business will be booming for you in the coming years, especially if you're located in Europe ;)
  - medlazik 2y ago
    This list of vulns nobody was ever bothered with except for 1 (Storm-0558) doesn't prove your ridiculously sensational comment above
- p_ing 2y ago
  Security issues/CVEs should never be used as a motivation to get off of a particular platform, otherwise we'd never use Linux, macOS, or Windows (I hope you're a fan of OpenBSD... sometimes). If these issues remain unfixed after being disclosed, or a pattern of fixes that took much longer than you feel they should have, that's valuable ammunition as it shows the organization isn't responsive to security issues.
  - nucleardog 2y ago
    I agree you shouldn't write off any platform/software/etc based solely on the number of vulnerabilities. I also agree that how responsive they are to fixing things is a factor to consider. But I think that's only _a_ factor. Take something like a container escape vulnerability. We could have Vendor A where they're just running containerd on a bunch of hosts on a single network segment and throwing everyone's containers at it so a container escape vulnerability essentially gets you access to everything any of their customers are running. Where-as Vendor B segments running containers into VMs, so a container escape vulnerability means you can only access your own data. Not great because if one container is compromised that gives them a path into the rest of your workloads, but at least I know they're maintaining a pretty solid wall between tenants. Then there's Vendor C that actually runs containers using some micro-VM framework so each container is running fully isolated by a hypervisor with a fully separate emulated network stack, etc so the escape really gets them no more access than they had inside the container. A pattern of issues like Vendor A is, well, a pattern. A series of issues that show their systems are fundamentally not designed for proper isolation between tenants and are lacking defense-in-depth measures to mitigate the fallout of the inevitable security issues is a very good reason to write off Vendor A regardless of how quickly they respond to the issues. I'm not going to go back and review all the Azure issues, but my recollection from the few writeups I've read definitely paint a picture of a lot more "Vendor A" type issues than I'd be comfortable with.
    - jiggawatts 2y ago
      All of this presupposes that whatever you implement yourself will be more secure and/or that you have the budget to even begin to approach the same level of security. I’ve been there, done that, and was amazed how the security aspects only rapidly escalated to many millions of dollars and an ongoing cost also in the million or two range! Think of this like a CEO: they’re less worried about Chinese hackers and more worried about about insider attacks. They’re much more common and do way more financial damage. The cloud automatically provides separation of roles because an entirely different vendor is in charge of the lower layers, such as networking and storage. Do you have any idea how hard it is to prevent a smart sysadmin from simply copying all data to a USB drive and walking out of the building with it? That’s much harder when everything is on a managed hosting platform and no single person can access all accounts / subscriptions.
- HideousKojima 2y ago
  Not strictly security, but there are several long-standing issues with Azure DevOps build pipelines and Artifacts feeds. Using a private artifact feed in your pipeline inexplicably adds minutes to the amount of time it takes to restore packages. And publishing C# NuGet packages together with the source/symbol files is a poorly supported and poorly documented mess (it doesn't help that NuGet support in the dotnet CLI is missing support for important and long requested features only available by using the full fat NuGet client or MSBuild directly).
- rubiquity 2y ago
  Azure requires that you use SHA-1 RSA private keys for initially connecting to VMs.
- Spooky23 2y ago
  They’ve improved a lot, but their Achilles heel used to be that the only way they could achieve more challenging compliance requirements was to have multiple segmented clouds. With Office 365, for example, they had at least 4 government clouds, some of which used shared infrastructure with Azure commercial, but had different data residency or employee requirements. They have thousands of employees monitored by all of the states as a condition of working on those clouds, for example. Technical controls are similar, but the weak point are things that can cross cloud boundaries. One of the Chinese breaches of US government systems were caused by a PKI vulnerability that allowed the attacker to pivot from a dev environment to a federal cloud instance.
noodlesUK 2y ago
I think it’s not just the security of the platform itself either that’s measurably worse - it’s also way easier to end up with insane security configurations with the hellscape that is Entra. It all just feels like it’s held together with duct tape. The deep integration with AD (now Entra) was the strongest selling point for Azure, but it’s also by far the biggest issue with the platform IMO. There’s also just no consistency in the platform - the CLI for instance has totally different flags and names depending on which sub command you’re using. It’s like this everywhere in Azure.
- _fat_santa 2y ago
  > There’s also just no consistency in the platform - the CLI for instance has totally different flags and names depending on which sub command you’re using. It’s like this everywhere in Azure. For all of AWS's faults, one of the reason I really like them is how consistent everything is. There were so many instances where I could correctly guess the right command for the AWS CLI based on how other services worked, I could never do that with GCP or Azure. I would love to read an article about how AWS ensures this kind of consistency. Given how Azure and GCP both messed this up, it's clearly not a trivial problem (even though it may seem like one)
  - dabbz 2y ago
    They have a governance panel for all AWS services that approves design docs and API contracts (at least this is what I was told by an old manager who worked on AWS back in the day).
    - patch_cable 2y ago
      It isn't quite as formal as that, but there is a group of engineers who review new APIs for following AWS-wide standards.
      - dastbe 2y ago
        there's also a significant amount of automation in place these days to sass you in the right direction, i.e. * focusing on resources and operations on resources * using consistent and expected naming schemes, pluralization, etc. it also helps that the sdks and clis are very raw wrappers around this, such that if you know what it looks like in the sdk then it will look similar in the cli.
christkv 2y ago
We just migrated off Azure after one to many deprecation or downtimes caused by some random new feature or change of how permissions work. We gave up.
rkagerer 2y ago
Not surprised, given its ancestry. This isn't a critique, so much as an observation. Microsoft's corporate culture evolved during some two decades under a very different threat model & security posture. A lot of the platform's foundations originate from that era, and although they've made significant strides you still see some of their other products struggle in this aspect as well (eg. good security primitives are there but they're sloppy in their default configuration and intuitability). Compare it to a platform that spent its youth growing up in a more actively hostile environment (like Bitcoin).

Mossy9 2y ago

As someone who is greatly motivated to moving off Azure (to onprem, not to another cloud), do you know of any good collection of Azure security issues I could use as 'ammunition'? Would be greatly appreciated! UPD: note to self - this seems like a good resource https://www.cloudvulndb.org/results https://www.cloudvulndb.org/results

redrove 2y ago
I have some notes somewhere but unfortunately they don't have citations, these are just some of the vulns they've had in the last couple years: • Storm-0558 Breach (2023): Chinese hackers exploited a leaked signing key from a crash dump to access U.S. government emails, affecting 60,000+ State Department communications • Azure OpenAI Service Exploitation (2024): Hackers bypassed AI guardrails using stolen credentials to generate illicit content, leading to Microsoft lawsuits against developers in Iran, UK, and Vietnam • CVE-2025-21415 (CVSS 9.9): Spoofing vulnerability in Azure AI Face Service allowed authentication bypass and privilege escalation • CVE-2023-36052: Azure CLI logging flaw exposed plaintext credentials in CI/CD pipelines, risking sensitive data leakage • Azurescape (2022): Container escape vulnerability enabled cross-tenant access in Azure Container Instances, discovered by Palo Alto Networks • ChaosDB (2022): Wiz researchers exploited CosmosDB’s Jupyter Notebook integration to access thousands of customer databases including Fortune 500 companies • Executive Account Takeover Campaign (2024): Phishing campaign compromised 500+ executive accounts via Azure collaboration tools with MFA manipulation If your company or workplace is considering migrating from cloud to on-prem or from one cloud to another, I do this professionally btw, feel free to reach out at this temporary email and we can chat: pale.pearl2178 at fastmail.com (to prevent my real email being scraped from HN).
- Mossy9 2y ago
  Great, thanks! For me it's just a distant dream now, but I bet business will be booming for you in the coming years, especially if you're located in Europe ;)
- medlazik 2y ago
  This list of vulns nobody was ever bothered with except for 1 (Storm-0558) doesn't prove your ridiculously sensational comment above
p_ing 2y ago
Security issues/CVEs should never be used as a motivation to get off of a particular platform, otherwise we'd never use Linux, macOS, or Windows (I hope you're a fan of OpenBSD... sometimes). If these issues remain unfixed after being disclosed, or a pattern of fixes that took much longer than you feel they should have, that's valuable ammunition as it shows the organization isn't responsive to security issues.
- nucleardog 2y ago
  I agree you shouldn't write off any platform/software/etc based solely on the number of vulnerabilities. I also agree that how responsive they are to fixing things is a factor to consider. But I think that's only _a_ factor. Take something like a container escape vulnerability. We could have Vendor A where they're just running containerd on a bunch of hosts on a single network segment and throwing everyone's containers at it so a container escape vulnerability essentially gets you access to everything any of their customers are running. Where-as Vendor B segments running containers into VMs, so a container escape vulnerability means you can only access your own data. Not great because if one container is compromised that gives them a path into the rest of your workloads, but at least I know they're maintaining a pretty solid wall between tenants. Then there's Vendor C that actually runs containers using some micro-VM framework so each container is running fully isolated by a hypervisor with a fully separate emulated network stack, etc so the escape really gets them no more access than they had inside the container. A pattern of issues like Vendor A is, well, a pattern. A series of issues that show their systems are fundamentally not designed for proper isolation between tenants and are lacking defense-in-depth measures to mitigate the fallout of the inevitable security issues is a very good reason to write off Vendor A regardless of how quickly they respond to the issues. I'm not going to go back and review all the Azure issues, but my recollection from the few writeups I've read definitely paint a picture of a lot more "Vendor A" type issues than I'd be comfortable with.
  - jiggawatts 2y ago
    All of this presupposes that whatever you implement yourself will be more secure and/or that you have the budget to even begin to approach the same level of security. I’ve been there, done that, and was amazed how the security aspects only rapidly escalated to many millions of dollars and an ongoing cost also in the million or two range! Think of this like a CEO: they’re less worried about Chinese hackers and more worried about about insider attacks. They’re much more common and do way more financial damage. The cloud automatically provides separation of roles because an entirely different vendor is in charge of the lower layers, such as networking and storage. Do you have any idea how hard it is to prevent a smart sysadmin from simply copying all data to a USB drive and walking out of the building with it? That’s much harder when everything is on a managed hosting platform and no single person can access all accounts / subscriptions.
HideousKojima 2y ago
Not strictly security, but there are several long-standing issues with Azure DevOps build pipelines and Artifacts feeds. Using a private artifact feed in your pipeline inexplicably adds minutes to the amount of time it takes to restore packages. And publishing C# NuGet packages together with the source/symbol files is a poorly supported and poorly documented mess (it doesn't help that NuGet support in the dotnet CLI is missing support for important and long requested features only available by using the full fat NuGet client or MSBuild directly).
rubiquity 2y ago
Azure requires that you use SHA-1 RSA private keys for initially connecting to VMs.
Spooky23 2y ago
They’ve improved a lot, but their Achilles heel used to be that the only way they could achieve more challenging compliance requirements was to have multiple segmented clouds. With Office 365, for example, they had at least 4 government clouds, some of which used shared infrastructure with Azure commercial, but had different data residency or employee requirements. They have thousands of employees monitored by all of the states as a condition of working on those clouds, for example. Technical controls are similar, but the weak point are things that can cross cloud boundaries. One of the Chinese breaches of US government systems were caused by a PKI vulnerability that allowed the attacker to pivot from a dev environment to a federal cloud instance.

noodlesUK 2y ago

I think it’s not just the security of the platform itself either that’s measurably worse - it’s also way easier to end up with insane security configurations with the hellscape that is Entra. It all just feels like it’s held together with duct tape. The deep integration with AD (now Entra) was the strongest selling point for Azure, but it’s also by far the biggest issue with the platform IMO. There’s also just no consistency in the platform - the CLI for instance has totally different flags and names depending on which sub command you’re using. It’s like this everywhere in Azure.

_fat_santa 2y ago
> There’s also just no consistency in the platform - the CLI for instance has totally different flags and names depending on which sub command you’re using. It’s like this everywhere in Azure. For all of AWS's faults, one of the reason I really like them is how consistent everything is. There were so many instances where I could correctly guess the right command for the AWS CLI based on how other services worked, I could never do that with GCP or Azure. I would love to read an article about how AWS ensures this kind of consistency. Given how Azure and GCP both messed this up, it's clearly not a trivial problem (even though it may seem like one)
- dabbz 2y ago
  They have a governance panel for all AWS services that approves design docs and API contracts (at least this is what I was told by an old manager who worked on AWS back in the day).
  - patch_cable 2y ago
    It isn't quite as formal as that, but there is a group of engineers who review new APIs for following AWS-wide standards.
    - dastbe 2y ago
      there's also a significant amount of automation in place these days to sass you in the right direction, i.e. * focusing on resources and operations on resources * using consistent and expected naming schemes, pluralization, etc. it also helps that the sdks and clis are very raw wrappers around this, such that if you know what it looks like in the sdk then it will look similar in the cli.

christkv 2y ago

We just migrated off Azure after one to many deprecation or downtimes caused by some random new feature or change of how permissions work. We gave up.

rkagerer 2y ago

Not surprised, given its ancestry. This isn't a critique, so much as an observation. Microsoft's corporate culture evolved during some two decades under a very different threat model & security posture. A lot of the platform's foundations originate from that era, and although they've made significant strides you still see some of their other products struggle in this aspect as well (eg. good security primitives are there but they're sloppy in their default configuration and intuitability). Compare it to a platform that spent its youth growing up in a more actively hostile environment (like Bitcoin).