Thursday, April 28th, 2011
In our previous How TeamWork Can Prevent Human Error in Production we discussed on the new feature of dbMaestro TeamWork for Oracle™ – Access Roles.
This new feature enables organization to add another layer of security on top Oracle. Usually when developers, DBA connect to oracle database if it the development, test or even production environments, they connect with the owner of the objects. During this connection any object can be changed since the owner has full permissions on its objects.
The organization needs another layer of security and this can be done using TeamWork for Oracle Access Roles. With this the organization can give specific permission to Active Directory account or group.
We recommend using Active Directory groups, assign them the right privileges in TeamWork and add the right members to this group.
Here is an example from real customer implementation:
This customer manages three environments: development, test and pre-production. They created the following Active Directory groups:
- DBA – Will be able check-out/check-in any object
- Developers – Can check-out/check-in only PL/SQL code (packages, functions, procedures)
- Read-Only – Can view object history but not change
- Release Managers – Can save version, freeze schema, remove and add objects from source control
People were assigned in Active Directory to the relevant group and each group was assigned with the right privileges based on the environment.
For example: Developers can check-out/check-in only PL/SQL code (packages, functions, procedures) in development and test environment, but in production they have Read-Only permissions.
You are welcome to contact us to hear how you can add another layer of security in your organization, just send us an email to sales@dbmaestro.com.
Posted in General | No Comments »
Tuesday, April 26th, 2011
One of our clients recently implemented dbMaestro TeamWork for Oracle in a rather unusual way. Most clients start their TeamWork implementation in the development environment when developers begin documenting changes using Database Change Management methodologies. But this client started its TeamWork implementation in its production environment to solve a critical database access problem.
The access problem existed because the same Oracle password was being used in every environment. It is not unusual that the password for the Oracle user is the same in the development, Integration, QA, and pre-production environments and sometimes even in the production environment. As a result, without Teamwork, changes to database objects could be made by any developer or DBA at any time without leaving an audit trail that indicated who did what when.
With TeamWork for Oracle the administrator can give developers access to change packages, procedures, and functions only in the development and QA environments while allowing them to review history in the production environment. This client assigned a role (developer, QA tester, release manager, DBA or read-only) to every person who could access the database for any purpose. Only people who were authorized to check-out objects in the production database could do so via TeamWork for Oracle. Everyone else could no longer do this.
Because the TeamWork security mechanism is integrated with the corporate active directory, this client achieved immediate control over access to the database in its production environment. For more information about database security, see Database Security.
Because TeamWork for Oracle’s change policy enforcement is integrated with the database engine, changed DDL files could not be executed in Oracle until they had been checked in via the TeamWork application. Only people who are authorized to check-in database objects can do so via TeamWork, so no one else could change the production database objects. In addition, only files that implemented changes associated with the work-plan for a release could be checked in to the version for that release.
When Teamwork for Oracle is implemented in the development environment, another source of human error is eliminated: manually produced deployment scripts. It is important to have a single deployment script for structure and meta-data. Meta-data is an essential part of the application logic. Deploying code changes without meta-data can cause an application to crash. Deploying structure changes to a meta-data table without the meta-data changes can produce incorrect values in the meta-data tables.
TeamWork for Oracle automatically generates a single deployment script that contains the structure and meta-data changes associated with an upgrade. This automatically generated script eliminates human errors in deployment scripts that are discovered only when the upgraded application crashes in the production environment.
In addition to gaining control over changes to the production database, this client now has an accurate up-to-date audit trail for every change made to its production database objects. This audit trail enables the client to determine what database changes were made after the people who made them have forgotten the details or even left the company. It also enables the client to satisfy the stringent accountability requirements of outside auditors. For more information about how TeamWork helps you comply with audit requirements, see Auditing.
Posted in General | 2 Comments »
Monday, August 30th, 2010
We are proud to release a new version of dbMaestro Teamwork™. Some of the exciting new features include:
- Added an internal security mechanism – Access Roles, which enables the administrator to set permissions on object types and action to a specific user within a specific project.
- Viewing the Database Schema from a Module Point of View provides database administrators (DBAs) with a view of the database schema from the point of view of a module. This significantly increases efficiency, making the jobs of both the DBA and database developers much easier.
- The managed schema’s password can now be saved in TeamWork client, eliminating the need to enter it repeatedly.
- Adding Search functionality in Source Control window, which allows you to find objects in specific status, for example: pending changes, objects being checked-out by different user and so on.
- New platforms added:
- Windows 2003 (64 bit) , 2008 (32 and 64 bit)
- Windows 7 (32 and 64 bit)
Additional fixes in the new version include:
- Several issues in content management.
- Supporting truncate command.
- Known Issue: Add-In will not start when using ODAC 10g on 64bit. Click to see the solution.
Posted in Release Updates | No Comments »
Tuesday, July 20th, 2010
In many applications, the initial design did not take security issues into consideration. For example, instead of having all objects in one schema, which leaves much room for risk of mistake or damage, one could split the tables to be in one schema, the packages and procedures in a different schema, and the user in a third schema.. Each schema has permissions to access the objects it needs (the application schema will have permissions to execute the procedures and packages, and the packages schema will have access to the query and the ability to change the data in the tables), thus significantly reducing the potential damage one can do. Over time, and as more and more changes were made, the problem got worse.
In development environments, the issue is even greater. Usually, all objects are in the same schema, making it difficult for a company with access and change protocols in place (i.e. that only DBAs can alter tables) to enforce them. To address this issue, DBAs created a dedicated user with the minimum permissions a developer needs. The developers login with that user. This, of course, makes the DBAs life more complicated, since they need to manually maintain another security mechanism.
An innovative, next-generation database change management solution, like dbMaestro TeamWork™ helps companies solve these challenges and overcome these limitations. It provides advanced permission management capabilities that give you full control over who makes changes to your databases, making it easy to proactively prevent unauthorized modifications to your schemas and their related objects. They work by allowing you to establish very granular access settings, giving each member of your IT or development team modification rights for only certain portions of each schema, based on their role and responsibilities in the application.
The key benefit of this approach is that it virtually eliminates the risk of accidental or incorrect changes to tables and other objects.
For example, use the permissions in your TeamWork environment to grant access to all tables to one team, allow another group to modify the procedures, and give yet another set of individuals the ability to change other objects – even if those objects all exist within the same schema.
Each member of your database management team will be able to view all database objects, but can only modify those they have been granted permission for. In other words, those users who only have full permission for tables can see the associated procedures, but cannot modify them, and vice versa.
Visit our Website to learn more about permission management, and the other innovative features of dbMaestro TeamWork – database change management software.
Posted in Technical | 2 Comments »
|
|
|
|
Loading...