We're trying to set up a central platform to assign groups to users coming from several organizations.
Each organization has its own identity provider, which we require supports SAML. Using SAML, we authenticate these users onto our platform in an isolated environment, i.e. users from one org should not be able to see users from another.
We were hoping to use Azure AD for this task and its Administrative Unit feature. Administrative Units proved ineffective though, as they don't allow this segregation. Either a users sees all users/groups in the AD, or none at all.
We also cannot use multiple Azure tenants, since we need to map these users onto AWS SSO, which only supports one tenant.
Are you aware of another identity service which allows SAML federated identity and org isolation?
• You can surely configure federated identity segregation and isolation using SAML with Azure AD by leveraging its various features like User based access control (RBAC or Roles Based Access Control) with authentication and identity separation, security assurances for processes and practices using Security Development Lifecycle, Identity based isolation, zero trust architecture, Azure Active Directory, Data encryption, key vault, and many others. The concept for user-based access control can be illustrated through the diagram below. Also, multi-tenancy in the public cloud improves efficiency by multiplexing resources among disparate customers at low cost; however, this approach introduces the perceived risk associated with resource sharing. Azure addresses this risk by providing a trustworthy foundation for isolated cloud services using a multi-layered approach depicted in figure below: -
• Also, do take into consideration that tenant isolation in Azure AD involves two primary elements: -
a) Preventing data leakage and access across tenants, which means that data belonging to Tenant A can't in any way be obtained by users in Tenant B without explicit authorization by Tenant A.
b) Resource access isolation across tenants, which means that operations performed by Tenant A can't in any way impact access to resources for Tenant B.
Access via Azure AD requires user authentication through a Security Token Service (STS). The authorization system uses information on the user’s existence and enabled state through the Directory Services API and Azure RBAC to determine whether the requested access to the target Azure AD instance is authorized for the user in the session. From the below figure, you can illustrate that Aside from token-based authentication that is tied directly to the user, Azure AD further supports logical isolation in Azure through: -
a) Azure AD instances are discrete containers and there's no relationship between them.
b) Azure AD data is stored in partitions and each partition has a pre-determined set of replicas that are considered the preferred primary replicas. Use of replicas provides high availability of Azure AD services to support identity separation and logical isolation.
c) Access isn't permitted across Azure AD instances unless the Azure AD instance administrator grants it through federation or provisioning of user accounts from other Azure AD instances.
d) Physical access to servers that comprise the Azure AD service and direct access to Azure AD’s back-end systems is restricted to properly authorized Microsoft operational roles using the Just-In-Time (JIT) privileged access management system.
e) Azure AD users have no access to physical assets or locations, and therefore it isn't possible for them to bypass the logical Azure RBAC policy checks.
For more information regarding the above, kindly refer to the documentation link below: -
https://aka.ms/AADDataWhitePaper
https://learn.microsoft.com/en-us/azure/role-based-access-control/overview
Related
I have done data masking and row level security based on the role of the user in snowflake. Now we are Integrating Tableau and Looker with snowflake using service account for these tools. Now since it is going to be a service account, which all the user will have access to. I am wondering how can we implement the masking and row level security.
Please note the access to snowflake is using SSO which is done by OKTA.
I am not very familiar with Tableau or Looker So wondering If we can do these security features from these tool or will have to bring in OKTA configuration(somehow) to configure this.
One way I am thinking to control this is by having multiple Service Account for the tool and depending on account assigned the role.
Or if people here can help me for how to implement this with a better way.
Snowflake has partnered with Tableau and Looker to integrate the access to Snowflake using OAuth.
Please refer to this document on how to set up the integration.
https://docs.snowflake.com/en/user-guide/oauth-partner.html
The user will log in to Snowflake using their own account via Tableau or Looker and all the data masking and row-level security that was applied to the user's role will take effect.
We currently have an Azure Active Directory tenant, which replicates via AD Connect our on-premises Windows users. We have an on-premises Exchange Server where accounts are my-company.com.
We have another email domain my-company.io for which there are no users yet.
In the immediate future, we want to create a few mailboxes for my-company.io directly in Exchange Online (not on our Exchange Server). These mailboxes will not be attached to Windows domain users.
Later this year, we want to start migrating our my-company.com Exchange mailboxes to Exchange Online, gradually with a hybrid setup.
In this scenario, what does make more sense?
a) Create second tenant in our Azure account, create there any my-company.io AAD users, then add these users to Exchange Online.
b) Add another domain to our existing tenant, create there any my-company.io AAD users, then add these users to Exchange Online.
Our concern is if activating Exchange Online for my-company.io users in the existing tenant, will interfere in any way our future plan to migrate to Exchange Online for my-company.com users.
Both methods should be feasible. The difference is whether the two accounts exist under the same tenant. If you have a reason to let them exist under the same tenant, you should choose the second option. But if you do not require them to exist under the same tenant, creating a new tenant for my-company.io is recommended, because this will reduce the configuration when migrating to Exchange Online for my-company.com users.
Your concern is not superfluous, but they are not unsolvable. If you choose the second option, then you need to carefully design what your hybrid deployment environment is like. For example, there are two types of users, one is a hybrid deployment user, and the other is a cloud-only user. You can refer to this document to choose the configuration you need.
In short, from the perspective of easy configuration and management of different types of users, the first solution is better, while the second solution does not require you to create new tenants and requires you to pay more attention to configuring hybrid deployments.
Recently observed that one can create multiple Service principals with the same name in Azure AD :
Note: They have different clientIds but same name. This in turn creates issues while creating users within Azure SQL.
So any reason why same name App Ids are allowed in AAD?
Also , a same client ID has different objectid when looked up via Enterprise applications and when seen via App registrations.
Is it because Enterprise applications is a union of all managed identities, Service principals etc , the objectid creation for Enterprise applications is different as compared to App registrations.
So any reason why same name App Ids are allowed in AAD?
Service principals and users in Azure SQL are totally different things. I don't think one is referential to the other. They designed it like this.
Generally speaking, when the value of a field is not allowed to repeat, it means that it is unique. I'm not familiar with Azure SQL, but it should follow this principle.
Why does Azure allows same service principal name? It's by design. In common scenarios, we mainly identify uniqueness based on its object id, which is globally unique identifier. Please do not use the name as the only condition for finding the service principal.
From a design point of view, we really should not create two service principals with the same name. It's a pity that Azure does not restrict this.
Also, a same client ID has different objectid when looked up via
Enterprise applications and when seen via App registrations.
An enterprise app and the associated app registration are two different objects, so they have different object ids.
The application id is actually the unique identifier for the app registration. It is just also shown in the enterprise app.
You can see Service Principal properties：
appId String The unique identifier for the associated application (its
appId property).
And the Application Properties：
appId String The unique identifier for the application that is
assigned to an application by Azure AD. Not nullable. Read-only.
Currently my team and I have a client that is using Power BI Premium.
We need to have Row Level Security enabled for both internal and external users.
We gave a recommendation to have Azure AD groups handle user management, but the client does not want to have all of there internal and external users be shown in their Azure AD. They believe it will be unmanageable for them. They want us to recommend another way to be able to manage internal users in Azure AD and have all external users managed in Azure AD, but completely separated from internal users, or by some other user management service that Azure provides. All the while, remaining in the same tenant since it seems the Power Bi Premium license can only be associated to one tenant and being able to have Row Level Security implemented for both internal and external users.
Is this possible? If so, how can we do it?
Thank you all for your time and help.
as per microsoft, https://learn.microsoft.com/en-us/power-bi/admin/service-admin-azure-ad-b2b
as far as I'm aware, the ideal way to share power bi with external users like that is this is to through azure b2b. which means you will have them as a guest user in your azure tenant. the second they are a guest in your tenant, that means they are on the list in your azure ad Users. which has advantages, their activity is trackable, reportable etc.
Our organizations has 10s of thousands of user accounts in our azure ad tenant, it doesn't make it any less manageable. just use the search bar or the filters, I'm not sure what the issue would be that makes it unmanageable.
if the requirement is secured power bi sharing,
you're better off trying to understand why your client thinks its unmanageable and help relieve their fears.
the only other option that I can see is, if you don't want to see external users, then you could use power BI embedded to embed power bi reports in a different web app that you create, and allow access to the webapp. but then you will have to deal with all the user level management stuff in code.
here's an article: https://medium.com/bi-helper/power-bi-embedded-report-distribution-to-external-users-1cf46fe1303b
hope this helps a bit.
We have developed an SQL based application for Motorsport and some of our clients are looking at Azure to hold the database. Trouble is they travel around the world to races and as such will need to access the database using what-ever Internet connection they have and cannot pre-define IP addresses in Firewall rules. Is it possible to effectively disable the Azure firewall so that they just need to enter login credentials to the SQL server rather than having to be on specific IP address ranges?
Given the whole idea of the SQL database is access anywhere it is difficult to believe that you have to define access based on IP addresses but I can't find anything which suggests otherwise!
Before giving you mode advice on security, to answer your question, Yes you can allow All inbound to your Azure SQL Database using the following T-SQL
EXECUTE sp_set_database_firewall_rule N'Allow Azure', '0.0.0.0', '255.255.255.255';
The range above allows all. This basically means this range is permitted to pass through firewall. This is for database-level firewall rule. For logical server-level rule, just setting the rule as follows
If database-level firewall rule is not set, the logical server-level rule is applied first.
First, giving direct access to your database over the Internet is a very bad practice from security perspective. Business/End-users are not often well trained in security awareness and the very high chance their computers are compromised. There are some approaches you should consider doing to improve security:
Use built-in Azure SQL Database security feature in Azure such as Transparent Data Encryption (TDE) to always encrypt your databases. If possible, use Azure Key Vault to store the encryption master key to add more encryption layer to the "whole" world. Another feature is Dynamic Data Masking but I don't think it is useful since you allow database access level. Of course, masking some fields is worth considering. Plus, enable Threat Detection to monitor if any anomaly queries (e.g. SQL Injection).
Integrate with Azure Active Directory to monitor access identity. Every access which is authenticated by Azure AD can be monitored and notified. In Azure AD, have a look at Conditional Access policy to see whether it is applicable to your business users. Saying all business users only travel to just a list of countries usually or they use managed computers. Azure AD (Premium) also gives you Sign-In Risk functionality which combines both Analaytics and Machine Learning to identify if a sign-in is potentially risky (from unknown person). If looking at Azure AD as an option, and more stronger then consider Azure AD Universal with Multi-factor authentication options.
Establish an Azure VNET, then configure Point-to-Site (P2S) VPN to your Azure SQL Database. Fortunately recently Microsoft announces the ability to control inbound to your Azure SQL Database inside a given VNET. After setting P2S VPN, give to your business users certificate. Such a certificate needs to be installed on business users' laptop before they can connect to the VNET. Attackers without having access to their computers have no way to connect to your Azure SQL Database.
Add an application layer (e.g. ASP.NET) and login page to let your business user access from this web application. This perhaps adds development efforts but this can help to eliminate at least some direct attack to your database connection string such as brute-force. In the application, handle SQL query to reduce direct SQL Injection. This way requires in-depth understanding of development.
If financial budget is limited, I'd highly suggest you to apply Azure AD and VNET first. Below is the cost drafting:
Azure VPN Gateway: $29.2/month ($0.04/hour * 730). Basic plan is enough. The plan supports up to 128 P2S connections. If your number of business users are greater than 128, just create a new VPN Gateway.
Azure AD: if you target to Free plan, you can store up to 500,000 users. If you like to use Conditional Access and reporting, you need to pay $6/user/month for Premium P1 plan
Azure SQL Database Auditing & Threat Detection: $15/logical server/month. If Auditing is enabled, you are charged Blob storage but the cost for Blob should not really a concern.
Azure App Service: if adding an application layer. The cost is around $60-70/month for small plan (Basic or Standard). Cost also includes development and deployment effort.
What I've said here may add more concerns on the effort, cost to build. Well, I'd leave that decision consideration to you. Just one thing, think about data breaches and your business reputation if an incident happens. The cost would be much more than the implementation.
I strongly advise against it, but if it's development database, you can create an AllowAll rule in the Firewall: How can I allow unknown users to access my SQL (Azure) DB?
Better option, is to use a VPN server so that the users have to log in to the VPN to have access to the database. This way the Db is not accessible to everyone. You can further secure the VPN by adding a sign in certificate so only owners of the certificate can log in to VPN.
My guess is that you have several options:
securing the database with Azure Active Directory users. Each user can login tot the database with specific rights you could also make them readers and disabling the firewall. You could even implement row level security.
Create a Azure API application that performs the actions on the database. Let the users login with there credentials to the api and pass those credentials to SQL server.
I think that in combination with row level security is one of the most secured options. On my blog: msftplayground I created a set of articles about it.