Make it simple on yourselves and your customers.

The PCI compliance center says: Scope: The Information Security Management System (ISMS) for Windows Azure, including infrastructure, development, operations and support for Compute, Data Services, App Services and Network Services are in scope for the PCI DSS Attestation of Compliance.

Which would seem to indicate that Azure is PCI compliant. The problem is that Azure encompasses at least 20 different services and not all of them are PCI compliant. For example Azure Web Sites ARE NOT PCI compliant because you can't turn off FTP. "Information Security Management System (ISMS) for Windows Azure" is meaningless to me as a customer, because i don't pay for "Information Security Management System (ISMS) for Windows Azure", I pay for Websites or VMs or Storage or Service Bus or whatever. I need to know if those things are PCI compliant.

A simple table with each service and a checkbox would be infinitely better than the current, *misleading*, 1 sentence you have about it now. And that 1 sentence is technically wrong because "Compute"(claimed to be compliant) includes Web Sites, which are NOT compliant.

I had to open a support ticket to find out for sure about Web Sites.

Love working with Azure services, but there are way, way too many instances where MS refers to Azure when they actually mean some subset of Azure services and it is really freakin' confusing.

Thanks

Certificate Services (ADCS/PKI/CA) should be offered as a service in Azure at least for infrastructure purpose such as machine certificates for MFM, Wi-Fi access and
for user web authentication e.g. to Azure itself. CA Private keys can be store in Azure Key Vault to be secured.
A hybrid client should be provided to support autoenrollment to Windows 7 and better clients to simulate a onprem Enterprise CA. The web interface should be in Azure and support other platforms than Windows.
I am willing to spend time and effort to be part of a user group, think tank, beta test group etc for such a service.

I am aware that SSL certificates can already be renew automatically, but there is a fleet of onpremise machines and tablets out there as well. Such a service can also be an addon in Intune.

I am aware of this posting https://feedback.azure.com/forums/216840-security-and-compliance/suggestions/397203-add-full-pki-implementation-with-certificate-manag and support this as well.

Currently Azure developers have to wrestle with how to protect the data that they would like to protect and retrieve with Azure Key Vault. Developers work in source control, and the data that they have to provide in app.config can be considered secret and/or sensitive. App.config can be checked into source control and can even be available as an open source project in GitHub for the whole world to see.

Even if a developer chooses to use a client ID and a certificate, the developer still has to provide a REST-based URL within the code base as well, and this can be checked into source control and/or be available publicly, exposing surface area that can be utilized for malicious purposes.

That means the developer ends up having to provide at a minimum the following information that might be checked into source control that provides surface area that can be utilized by a malicious party:
Client ID: the application ID used to access the data (the who).
REST URL: the location to retrieve the data (the where)

Obviously, the malicious party would still need the certificate to do any real damage. But, having the REST URL (location) and Application ID (the identity) is still a lot of information that can be checked into source control (and at this point, is almost expected to be checked into source control), and some innovation should be considered here to mitigate existing risks.

Please consider improving this area so that developers reduce their exposed surface area and do not expose themselves to malicious parties when checking their code into (public) source control.

Smart cards allow for a very high level of security. This is why Microsoft uses it for employees who need remote access to the Microsoft network. It’s difficult for an external computer to log onto the Microsoft network without a smart card. A user name and password is not enough.

A smart card would give some corporate customers confidence if they could give their employees a more secure way for logging onto their applications than standard credentials.

External consumers might want it too, to safeguard their identity. Such customers would have a choice of either the standard login or enhanced login.

Scenario:
A user logs on using their Windows Live credentials. They can then change their Windows Live preferences. They can set their preference to accept either standard login with user name and password, or enhanced security with user name, password and smart card.
Alternatively, a user could opt to log onto Microsoft Live with just their Smart Card.

For those using enhanced security, the user gets logged out when the smart card is removed from the reader. Since security related employee and customer information is never stored on the computer, the loss of a computer is not a danger. The loss of a security card is also not a danger since it can be revoked.

The Identity token generated would mention weather enhanced security was enabled. This is for corporate customers who require it. Such corporate customers who require enhanced security would be responsible for issuing cards and replacing lost or stolen cards.

I would love to have a possibility to control what endpoints you are allowed to manage your Azure Services from. Like an ACL, management can be done from these endpoints (ip addresses) and from no place else. Today we have to use ADFS and special domains in the UPN to be able to resolve this. But it doesn't apply for all accounts.

So having that possibility would be great. Jump Servers has been used for many years in the on-prem world. And even if you use MFA there is no way to guarantee that the endpoint that you are managing from isn't compromised.

I would like to use a Jump Server and Limit the Endpoints where the management can be run from.