With KAFKA one can use SSL certificates. I am familiar with this approach https://www.ibm.com/docs/en/cloud-paks/cp-biz-automation/20.0.x?topic=emitter-preparing-ssl-certificates-kafka and that a REST API producer or JAVA program producer can implement this as well for writing KAFKA topics.
From the AZURE docs on Event Hub I cannot determine if, when sending a message to Event Hub with KAFKA API approach, whether this is also possible. I find the stuff hard to follow on AZURE.
I see this https://learn.microsoft.com/en-us/azure/event-hubs/event-hubs-for-kafka-ecosystem-overview, but:
The section on Shared Access Signature (SAS) https://learn.microsoft.com/en-us/azure/event-hubs/event-hubs-for-kafka-ecosystem-overview#shared-access-signature-sasstating SASL_SSL is that the same as SSL certificates
And what does PLAIN mean?
Note this all pertains to a small account in AZURE with no AD Grouping applied.
My take is that SASL_SSL amounts to the same as SSL that I note at the top of the article and that no AD Groups are needed. Please confirm.
No, you cannot use SSL certificates to authenticate to the Kafka Endpoint of Azure Event Hub. See here for the two possible auth options:
Azure Event Hubs provides multiple options to authorize access to your secure resources.
OAuth 2.0
Shared access signature (SAS)
The latter is basically a password. SASL_SSL is just the protocol and you use it no matter which of the two options you choose. The connection must always be made with SSL encryption enabled but that is different than using certs for auth.
Related
We are developing an Azure multi-tenant web service portal that calls external API services. Each called web service may have oAuth parameters such as end point, client Id, secret, etc. Currently, we 2 flavors of working code:
uses SQL to store these parameters; and
uses a json config file to maintain runtime parameters. I would like to offer a Azure Key Vault solution, but it seems unwise to have both a Client ID and Client Secret in the same Key Vault.
Additionally, we have many subscribers in our multi-tenant model, and each may have a specific config (for example: Solr collection name, SQL Db connection string; etc.) and I am wondering about comingling these runtime parameter verses allowing the customer to have their own Vault which of course requires that the customer share access with us as a SaaS vendor. We want to offer best practices security to our subscribers, many of which are Fintechs. Any advice is appreciated.
"but it seems unwise to have both a Client ID and Client Secret in the same Key Vault"
Why would you store these in the same database or JSON - far less secure.
Have you looked at Azure API Management, this is by far the best way to amalgamate services.
If you are too far down the road, use KeyVault. Use MSI (Managed Service Identity) to connect from your app service / function app, limit access Keys, Secrets, Get, List, Read, Write. Limit access via the firewall. Make sure all diagnostics are logged.
If you need a per-client model and not a multi-tenant, then deploy separate instances of the portal or API management for each. Per-client is more expensive and more tricky to maintain, but far more secure because you can enforce physical partitional on a number of fronts.
I am currently thinking about a solution where an IoT device would have more than one possible endpoint to talk to. Like an API for some calls that do not concern telemetry or device twin data.
The connection to the IoT Hub can be secured very well (we will use certificates), and I want to awoid adding a different way of authentication to the architecture.
So my idea right now would be to have a back-end service generate device specific SAS tokens for my APIs, possibly on-demand if requested by the device.
The Cloud-to-device communications guidance mentions configuration data, so it feels like a good way to go. Would it be safe to write these tokens in the desired properties? Would it be safer to use the payload of a cloud-to-device-message? Or should it be done completely differently?
You can create a custom cloud service as a token service that uses an IoT Hub shared access policy with DeviceConnect permissions to create device-scoped tokens.
For more detailed information you can reference "Custom device authentication".
I know that Azure Service Bus is secure while in transit because of SSL, but I'm unable to find any information about if it's encrypted while at rest.
If the content of the message is sensitive in nature, can Azure be relied on to keep messages private while within the Azure infrastructure - or should we implement message security?
As of 4/25/2018, the page that #tyler-pollack referenced, has been updated to specify that encryption at rest is provided at all tiers.
https://learn.microsoft.com/en-us/azure/security/azure-security-encryption-atrest
You can see the update in this github commit: https://github.com/MicrosoftDocs/azure-docs/commit/66214db8a21eefcece6441ae566041b90b2615fa#diff-f55bddd3fba462832c4a2d0e7918f750
You will have to encrypt the data yourself. There are currently no facilities built into the service bus for data at rest.
Service Bus Premium currently supports encryption at rest - https://learn.microsoft.com/en-us/azure/security/azure-security-encryption-atrest#azure-resource-providers-encryption-model-support
We want to enable Geo-Replication in Azure SQL Database. However for compliance reasons, we want to be sure that replication to secondary region happens over a secure encrypted channel.
Is there any documentation available to confirm that data in-transit during geo-replication goes over a secure encrypted channel?
I have looked into Microsoft Azure Trust center and there is a brief mention about using standard protocols for in-transit data. However I could not find information related to which protocols are used and how security of in-transit data is ensured.
Thank you for this question. Yes, the geo-replication uses a secure channel. If you are using V11 servers the SSL certificates are global and regularly rotated. If you are using V12 servers the certificates are scoped to the individual logical servers. This provides secure channel isolation not only between different customers but also between different applications. Based on this post I have filed a work time to reflect this in the documentation as well.
So I have a mobile app that uses AWS's IAM infrastructure that effectively allows me to provide temporary access tokens to anonymous mobile devices, so that they can run queries against AWS services directly from the mobile device.
Does anyone know if Windows Azure has a drop in replacement for this sort of thing too? I've read about Windows Azure Access Control but all examples seem to focus on allowing authentication via the likes of Facebook, Twitter or Windows Live etc. In my case, I don't want the mobile user to have to "log-in" anywhere, I just want them to be able to access Azure services such as table storage, without having to go via my server.
Thanks!
You do have the ability to create Signed Access Signatures for all three Windows Azure Storage services (BLOBs, Queues and Tables) as well as for Windows Azure Service Bus Brokered Messages (Queues, Topics & Subscriptions). These SAS urls are temporary and you can create them ad-hoc with expiration times. After that time expires the device would have to request a new one, likely from your server. This reduce the load as they aren't coming back all the time, but you do still have to run something that will gen these SAS uris for the devices. You can generate SAS manually against the REST API direct, or you can use one of the SDKs to generate them for you (which also hit the REST API).
Note that when you create a SAS you have the option of doing so as a Policy, or adhoc. A policy allows you to revoke a SAS at a later time, but you can only have so many of these defined at a time (likely too big of a restriction for a mobile scenario if you are doing by device). The adhoc approach allows you pretty much as many as you need (I think), but you don't have the ability to revoke it, it just has to expire.
Another option is to look at Windows Azure Mobile Services. This service runs on servers managed by Microsoft and you can use it to get at just about anything you want. You'd want to look at the "Custom API" feature. Also, make sure you understand the pricing model of mobile services (or really, that stands for any option you decide to go with).
It's called managed identities in Azure