I have an AppSync app defined using a master CloudFormation stack and more than a dozen nested stacks. Each nested stack defines a DynamoDB table, an AppSync DataSource for that table, and an IAM role for that DataSource to access that table. The DataSource depends on the role, which depends on the table.
I would like to consolidate these IAM roles, for three reasons:
The role definitions are very repetitive and boilerplate-y.
There are many copies of this app, and it adds up to a lot of IAM roles — enough that we're running close to the soft limits.
Some resolvers use DynamoDB batch operations to access multiple tables, so at least some of the IAM roles must grant access to multiple tables anyway.
I do not want to give the role blanket access to all DynamoDB tables in the account.
The simplest way to grant one role access to every required table would be to list them manually in the policy document. This has the obvious downside of requiring that the policy be manually kept in sync when new tables are added. However, there is also a dependency problem: the DataSource in a nested stack depends on a role in the master stack, which depends on tables in the nested stacks.
I would have liked to use tags: grant for all DynamoDB tables that have a certain tag, then set that tag for each table. This way, the IAM role would not need to be edited when a new table was added. But apparently DynamoDB does not support tag-based conditions.
Is there an easy way to grant a single IAM role access to many DynamoDB tables without granting access to all of DynamoDB and without individually listing the tables in the role?
If you can name your tables in a way that gives them the same prefix you can use wildcards in the resource.
arn:aws:dynamodb:<Region>:<Account>:table/MyPrefix-*
That will work on all tables that start with MyPrefix-
If you are using generated names you can probably use the AWS::StackName value in place of MyPrefix but be aware that with nested stacks that value may get shortened.
I used the DataDog Audit bundle in order to log every action that happens in my MySQL database. However when I check the diff column in the audit_log table I can't find the ID of the respective entity that have been updated/inserted/deleted etc. I also can't find which user is responsible for a certain action. Does anyone know if the DataDog audit bundle saves the ID of the entity to which action are performed and if this is the case where I can retrieve this data?
Yes it does have this functionality in the Audit Association entity. The entity stored with the blame_id in the Audit Log entity contains information regarding the user. The one with source_id contains information regarding the entity itself and thus the ID of the entity in the fk field.
How can I associate two entities, each in a different database.
I have created two entity manager one for each database, default and customer_1.
You cannot associate entities in different databases, at least not in the latest Doctrine version.
Moreover this is not advisable as the underlying database server (ie. MySQL) will not be able to guarantee data integrity across independent databases. Foreign keys for example do not allow you to reference keys outside the parent database.
The multiple entity managers as envisioned by Symfony here http://symfony.com/doc/current/cookbook/doctrine/multiple_entity_managers.html are meant only for accessing different bundle sets in the same app. If you want to associate your entities you'll have to use one database.
This question is an extension of my previous question. The prior question uses a similar approach but only uses active directory to populate cookies or session variables, which is useful only for simple things like populating a dropdown. Here I am extending that approach to populate a database table. The extended approach provides a technique for securing data in by creating joins in the database.
Please comment on whether this is a "good" approach to securing database data through active directory.
Scenario Need to create an application for submitting & viewing accidents reports that will be used by 50 schools. The application needs a security mechanism to prevent employees from viewing data that is not in their school(s). Some employee's are to be assigned multiple schools. The IT department wants to create a security group for each school in Active Directory to control access to the application and it's data.
Problem with Active Directory
If not using Active Directory I would simply create a database table called UserSchool which would store the username and SchoolID. This would make it very simple to write queries that return data only pertinent to user's school. I would just have to add a join to the UserSchool table in my stored procedures.
Possible Solultion This solution is an attempt to gain the best of both worlds. Security will be managed through Active Directory. When an employee logs into the application the UserSchool table will be populated from Active Directory.
Create an OU in Active Directory called AccidentReportingSchools.
Create a security group for each school in the AccidentReportingSchools OU.
To each security group, add an attribute called SchoolID which corresponds to the primary key of a table called schools.
Create a table called UserSchools that will have an Username and SchoolId field.
When an employee logs into the application a delete statement such as DELETE FROM UserSchools WHERE UserName = #UserName.
After running the delete statement the table would be populated with their UserName and SchoolID which will be taken from the Active DIrectory security groups.
The ability to add, update, and delete various entities in my application is often determined by the relationships defined between the various users involved. Here is an example:
A basic user or his supervisor can create tasks associated to the user, but only his supervisor can lock down the task so that the basic user will not longer be able to add/update/delete it. Until locked down, both individuals will be able to update the task.
What is the best approach to implement these kind of complex and advanced rules that deal with the relationship of users and the state of the entities (new, existing), as well as other things like maybe a user-defined status associated to the entity?
Thanks
What is the best approach to implement these kind of complex and advanced rules that deal with the relationship of users and the state of the entities (new, existing), as well as other things like maybe a user-defined status associated to the entity?
You want to use an authorization standard, namely XACML, the eXtensible Access Control Markup Language. XACML is:
a standard developed by OASIS, just like SAML is
a standard that focuses on fine-grained access control: access control that takes into account user information, resource information, state, and contextual information
a standard that implements the attribute-based access control (ABAC) model: the user information, resource data, and state can all be seen as attributes
a standard that uses policies and rules to structure the attributes and grant / deny access: XACML is policy-based
a standard that can be applied across multiple layers e.g. across the presntation tier, the data tier, the business tier of an MVC application
a standard that can be applied to multiple technologies and languages e.g. C# (MVC4 and more), Java, Python...
With XACML, you can easily implement relationships e.g.: an employee can approve a transaction if and only if the transaction amount < employee approval limit AND the transaction is not locked.
Where to go from here?
Check out NIST's page on ABAC.
Check out OASIS XACML's page and spec
Check out existing implementations (open-source and vendor such as the one I work for, Axiomatics.)
At a bank I worked for, we had a loan management system that allowed the entire bank hierarchy to see loans in their reporting structure. For instance, a Market exec could see the loan portfolio of all of his/her reports at once. Additionally, s/he had the ability to select from a list of all reports' (direct or indirect) names to view the portfolio of that employee.
It was complex, but we had to maintain an HR database of the reporting structure. Once we had that, we built user functions (could be done as stored procs, too, but user functions worked well in our LINQ to SQL backend) that allowed us to check whether user x supervises user y.
So, in your example, as long as you know who owns the task, and have access to a method that can be used to determine if the task owner reports to the currently-logged-in user, you should be able to easily enable/disable the "lock" button on the page.
The legwork lies in creating that reporting structure DB, and keeping it up to date!