Kusto restrict all table and function except specific table - azure-data-explorer

Right now Kusto provides restrict statement for middle-tier application to limit access to database and database's table/function. According to docs https://learn.microsoft.com/en-us/azure/data-explorer/kusto/query/restrictstatement?pivots=azuredataexplorer, there is no option to exclude a specific table from restrict statement. Is there anyway to do this without listing all the tables/functions that my client allowed to query on?

Restrict does not support exclusion, however if you want to restrict access to a specific table you should consider enabling the RestrictedViewAccess policy on that table. This means that you will have to explicitly allow access to the table for a specific set of users and everyone else will not be able to access it.

Related

Adding properties to output of current_principal_details() in Azure Data Explorer

I am implementing Row Level Security in Azure Data Explorer, I am using
current_principal_details()
To get information about the user but how can I add the names of the groups or something that the user is part of?
I cannot use
current_principal_is_member_of()
Since I will have over 6000 groups and the RLS query will be just too long so my idea is to add groups or roles or something to the user that I can see using
current_principal_details()
And the parse them and use that as input to the RLS query
I am using the following KUSTO to get the info of the user
print d=current_principal_details()
I just need to know how to add properties to the output and use them as input to RLS query

Firestore Security Rules Shared Document by Group

I have a situation where a user can create a doc and then share it with a group of other users. They could share it to multiple different groups. I don't know how to set a rule for this.
Here is the database structure:
So in the group you have a list of docs that have been shared to it. My app loads the group that a user is in, then wants to load all the docs in the documents array. I need a way server side to say that this is OK. Up until now only the owner of the doc can read it.
I put a field in each doc that contains ids for each group its shared to. I think I want to say "check if the user is a member of any groups in the sharedToGroups" list but I can't work out how to do that unless I maintain another list somewhere say in the userProfile doc that has a list of circles the user is a member of. Even then I'd be trying to compare 2 lists and I'm not sure I can do that client side.
It would be nice to be able to get the group Id somehow from where the request is being issued from and just see if that is in the sharedToGroups array.
Any help or comments on how this can be achieved would be greatly appreciated, maybe it needs a different db structure.
You can try an approach of this sort:
I am not sure if this will help you but off the top of my head maybe you could enable permissions on firestore for the group document. As in, in the rules, for the group set up a function that validates the user with the user ID stored in the document with the ID attached in the auth via the firebase auth
Therefore, rather than trying to restrict access per document, restrict access per group.
I'm going to answer my own question. Not sure if its the correct protocol here (not a professional programmer or experienced Stack Overflower) but it might help someone.
I ended up adding a field in the user_profiles document that has a list of each group they are in. This list needs to be maintained as I create and add / remove people from groups along with the members list in the group itself.
The benefit of this is that I can use the users id from the request object to get that document from the data base in the security rule. I then have a 'sharedToGroup' array in the doc I'm trying to access and a "inGroups" array in the user_profile that I can access also. Then I use the hasAny operator to compare the two arrays and allow access if the sharedToGroup array has any values from the inGroups array.
My rule becomes:
match /_group/{groupId}{
allow create: if isSignedIn();
allow read: if isOwner()
|| resource.data.sharedToGroup.hasAny(get(/databases/$(database)/documents/user_profiles/$(request.auth.uid)).data['inGroups']);
allow write: if isOwner();
}
Only thing left to do is to secure the user_profiles doc to make sure not even the user can write to it since I don't want someone manually adding groups into their array.
I hope this might help someone someday - like I said I'm a not a pro here so take it with a grain of salt.

Firebase order by existence of a child

I have a very large database of users that I need to paginate through. The structure is as follows
users > -userId > logs > -logId > {type, timestamp, ...}
Not all users have logs so according to the data order docs if I orderBy "logs" these users should appear first (https://firebase.google.com/docs/database/web/lists-of-data#data-order)
When using orderByChild(), data that contains the specified child key
is ordered as follows:
Children with a null value for the specified child key come first.
As a result I am trying to use the following code to retrieve the last 5 users with logs but am running out of memory on the cloud platform (2GB). Should I be adding an index to assist with this query or is my syntax here incorrect?
admin.database().ref("users").orderByChild("logs").limitToLast(5).once("value", (snapshot) => {
Is there a better way to fetch a limited group of users who have logs? Any feedback would be appreciated
Should I be adding an index to assist with this query or is my syntax here incorrect?
The answer to that is always yes. Without an index in your security rules, the server will send all data at the location to the client, which then orders and filters it.
So for your query, your rules will need to contain an index on logs under the users node.

crm 2015 online prevent the possibility of adding new record from lookup

Someone know any way to prevent the possibility of adding new record from lookup field?
I want that the users be able to choose only created records. but they couldn't create new from the lookUp.
thanks!
You need to create a security role for your users defining the permissions you want them to have. You will need to have CREATE permission turned off on the lookup entity you don't want them to create.
One source with further information about Security Roles is here:
http://crmbook.powerobjects.com/system-administration/business-administration/security-roles/

ASP.NET user browse selected/restricted raw data from sql-server

In an ASP.NET WebForms application I would like to allow the end-user to browse selected raw data in an sql-server database.
However, I would like to restrict access for the user to only view some of the data based on the username.
I'm not sure how to do this in a way that is possible for the user to understand, since SQL is not necessarily known to the user.
What options do I have here?
As a basis for this I have considered creating one sql function per table in question. That function should return the data that the user is allowed to view, e.g.,
CREATE FUNCTION ufn_RawData_Employee(#username nvarchar(256))
RETURNS TABLE
AS ( SELECT * FROM Employee
WHERE [#username is allowed to view the given Employee] )
In a webpage the end-user might then type an SQL-like statement like
SELECT Name, HireDate FROM ((Employee))
where (([TableName])) then could be replaced by ufn_RawData_[TableName]([UserName]) before calling the database.
(For security reasons such calls could then be performed by a sql user whose only permissions are SELECT permissions to these functions.)
However, this approach might be too difficult for the end-user. I would like to know if an easier/user-friendlier solution exists for the end-user to browse selected raw data?
If you are only showing the user data from one table, or one view (which would probably be more useful) then yes you could store the name of that view in a table and retrieve it with a function. You could then display the data in pages, and make sure your standard select scripts have a built in search function if necessary.
There is no need for the user to write SQL if they are only getting data from one table or view. If you need to provide multiple potential tables/ views, then let them choose from a drop down, but it doesn't sound worthwhile to allow them to write their own SQL queries.

Resources