DB-14: OpenEdge® Database Run-time Security Revealed

DB-14: OpenEdge® Database Run-time Security Revealed
This is Exchange 2007 session “DB14: OpenEdge Run-time Database Security Revealed”. My name is Michael Jacobs, and I’m a Development Architect in the OpenEdge group. This is 90 minute intermediate session that is targeted for OpenEdge application architects and developers. My expectations are that you are already familiar with the OpenEdge RDBMS database and its basic administration utilities. More and more I get questions about OpenEdge applications that are being required to meet run-time security requirements that have been placed upon them. The OpenEdge database actually has a number security features that can be very useful in these circumstances. Many of these features you will not find documented very well, if at all. During this next 90 minutes, my task is to provide you with information about those OpenEdge database run-time security features, and show you how to get the most out of them. Michael Jacobs Architect, Progress OpenEdge

Agenda Run-time database security landscape
OpenEdge 10 database security Comparing run-time and compile-time Configuring run-time database security I have four topic in this session: A brief overview of run-time database security A view of the OpenEdge 10 database’s security features A short discussion on the differences in security between ABL compile-time versus ABL run-time A section on tips to configuring run-time security DB-14: OpenEdge Database Run-time Security Revealed

Database Run-time Security Drivers
Why motivates us to use run-time database security: Because you have to Government regulations Industry standards Personal data privacy requirements Legal liability Imposed $$ penalties It is all because of the hackers They have tools They have the knowledge They have the motivation Run-time database security is not new, but has not been pushed hard by governments and the computing industry until recently. Chances are that you either have been, or will be, pushed to configure your application to use up-to-date security features, many of which are implemented by the database server itself. In the news recently, I’ve seen where a company has been levied with a substantial fine for not implementing enough security features to protect information. There are other “rumors” where banks and insurance companies will begin imposing their own monetary penalties if you don’t use security features considered to meet industry standards. The biggest push will come from the hackers themselves. They have more than demonstrated that they have the tools, knowledge, and motivation to get into many business, abuse and bypass older application’s security in order to access their information. DB-14: OpenEdge Database Run-time Security Revealed

CSI/FBI Computer Crime & Security Survey
2006 respondents reported : 48% detected 1 – 6 security incidents 68% reported losses due to insider attacks Average loss ~$168,000 Top reasons for loss Viruses Unauthorized access to information Laptop / mobile hardware theft Theft of proprietary information Top security issues Data protection & application security Policy & regulatory compliance Identity theft & leakage of private information Everyone has to have some substantiation for saying this things. For this I’ve pulled some information from the combined CSI (Computer Security Institute) and U.S. FBI (Federal Bureau of Investigation) annual security survey. Sixty-eight percent of surveyed businesses sustained losses due to insider attacks, and the second highest cause was the unauthorized access to information. In looking forward, the surveyed businesses considered that data protection and application security was the top problem to fix in 2007. All of these issues point in the direction of using database run-time security. DB-14: OpenEdge Database Run-time Security Revealed

(index blocks) OS Files (record blocks)‏
Database Security In a perfect world, the application stack has no security holes: (Black-hat hacker) OS/Network Security Application A Application B Application C xDBC Driver xDBC Driver xDBC Driver In a perfect world, the network and system security provides a solid barrier to black-hat hackers and that our application stacks provide solid protection around the business’s data. I’ve shown the hacker with the little black-hat symbol to represent the “black-hat hackers” who are intent on stealing/destroying company information. DB Server Database Utilities RDBMS (cache files)‏ (index blocks) OS Files (record blocks)‏ DB-14: OpenEdge Database Run-time Security Revealed

(index blocks) OS Files (record blocks)‏
Database Security In reality, the application stack has many vulnerabilities : OS/Network Security Application A Application B Application C xDBC Driver xDBC Driver xDBC Driver However, in reality the hackers have demonstrated that . The OS & network security has holes . The network traffic can be obtained . Database utilities can be used as hacker tools . The file-system will provide direct access to much sought-after information The worst, and what this session will concentrate on is where the application code is bypassed, or replaced by, something written by the hacker to take advantage of an application’s security weaknesses. DB Server Database Utilities RDBMS (cache files)‏ (index blocks) OS Files (record blocks)‏ DB-14: OpenEdge Database Run-time Security Revealed

Database Run-time Security’s Role
Block application-code attacks & inappropriate user access : SQL sets the standard for database run-time security User authentication Database administration View, table & column access controls Database vendors add security features Multiple user authentication systems User connection privileges Role & user-group privileges In today’s world, the SQL standards set what is considered to be normal for database security. In there you will find . User authentication . Database administration . Access control to data When I look close at some of these regulations and standards, I see that the writer assumes that database implements SQL standard security. Database vendors will also add extra security features that have been requested by their customers in the form of additional user authentication and privileges to protect sensitive resources and operations. DB-14: OpenEdge Database Run-time Security Revealed

OpenEdge 10 database security Comparing run-time and compile-time Configuring run-time database security That’s one reason for understanding the run-time security features available to your OpenEdge application, which is what I will show you next. DB-14: OpenEdge Database Run-time Security Revealed

OpenEdge Database Security
One database – two security systems : SQL Server ABL Core application ISUD user authentication user authentication application CRUD user accounts user authorization user authorization SQL Privileges ABL Permissions SQL Tables Public Tables OpenEdge RDBMS Database storage engine performs no security operations SQL & ABL clients provide all database security The OpenEdge database is a single database storage unit that has two separate and distinct security systems. The OpenEdge storage system performs no run-time security checking, all authentication and access to data is controlled by its clients the SQL server and ABL core. The storage system simply accepts or denies connection based on the client/shared-memory version. Those two storage engine clients: . Share a common set of user accounts . Have separate storage and enforcement of access-control privileges . Share a common set of public data tables . With the addition that the SQL server also provides selective access to SQL-only data tables DB-14: OpenEdge Database Run-time Security Revealed

Comparing ABL & SQL Security Systems
Security model GRANT Default DBA n/a <db-owner> SYSPROGRESS Default security administrator “*” Default table access <none> Default field access If we compare the two client’s security systems, you will notice some interesting information. I’ll let you read through the details later, but the highlights are: To many people’s surprise, the ABL core’s authorization implementation employs the GRANT model the same as SQL. Implementation wise in the ABL, no database connection user-id has access unless explicitly granted it. The second is that SQL employs the traditional definition of DBA, which the ABL does not. However, the ABL security system has a defined Security Administrator who is limited to managing user accounts and the data those user accounts can access. The primary difference between ABL and SQL is that the ABL’s defaults are made for a development environment where PUBLIC access is granted to everyone to the entire database. SQL employs a more production site approach in that it denies access to all until it is granted. ABL developers need set any security, but they need to configure security for the production sites. SQL developers needs to set security in the development environment but is securely configured for production sites. DB-14: OpenEdge Database Run-time Security Revealed

OpenEdge Database Auditing
How do you know the security systems have not been compromised ? SQL Server ABL Core application ISUD user authentication user authentication application CRUD user authorization user authorization Audit Rules policies.xml OpenEdge RDBMS No SQL or ABL database record operations can bypass auditing Security systems, like everything else, run from configuration rules to customize the run-time for defilement installations. So who watches over the security subsystems so that you can detect when those security configurations change? For that answer, you can use the OpenEdge database auditing service. The OpenEdge database auditing service can be configured through a set of rules to audit only those database operations you want to monitor so that performance is minimally impacted. The auditing subsystem monitors “every” record operation by any storage system client. You can configure OpenEdge to not audit some tables and fields, but you cannot have the storage engine perform any operation without its knowledge. According to what is configured, audit information is recorded real-time so that it cannot be lost and can be immediately available. This means that any change in user accounts, schema, or user authorization privileges cannot be bypassed and you can always have a complete history of who changed what security configuration. The auditing subsystem can do much, much more, but that is the subject of another session. I only want to add it here in terms of monitoring the OpenEdge database’s security related information. Audit subsystem Audit Data Schema & data Tables DB-14: OpenEdge Database Run-time Security Revealed

User Authentication DB-14: OpenEdge Database Run-time Security Revealed

Shared ABL & SQL User Accounts
_User table accounts : Two required fields user-id (_Userid) Maximum length: 12 Illegal characters: < 32 or password (_Password) ABL: Changed only by the account’s owner SQL: Changed by DBA or the account’s owner Password field: fixed-length CRC-16 hash Beware of default SQL DBA account definitions <db-owner> (DBA privileges) SYSPROGRESS (DBA privileges) PUB (table owner privileges) The OpenEdge database has a single, shared, set of built-in user-accounts. This is important, especially if SQL server is part of your application solution. The top question is what are the minimum required fields: the user-id (_Userid) and the password (_Password). The rest are optional and not used by OpenEdge. You can assume that there are no other rules used by OpenEdge because there are no other fields used and no account policy configuration. The user account name has a effective maximum size of 12 characters and can use any character except those whose value is < 32, “#”, “*”, “,”, “!”, or which are restricted to OpenEdge use. The owner of the account and the SQL DBA can always change an account password. In the ABL, if you are not the account owner you have to recreate the record with the changed password value. The next question I get is about the storage of the password: It’s a non-reversible hash, so nobody can “decrypt” it. Because SQL server has built-in user-ids, you can add _user accounts with these names and actually log in and inherit all of their [DBA] privileges. DB-14: OpenEdge Database Run-time Security Revealed

ABL & SQL _User Account Behavior
Without _User accounts User-id: OS process id Cannot use –U –P to connect With _User accounts Default user-id: “” -U/-P must match _user account Can always CONNECT as default user-id Without _User accounts Default user-id: none Connect with any user-id except “PUB” “SYSPROGRESS” (passwords ignored) With _User accounts MUST authenticate to _User account PUB & SYSPROGRESS accepted as user-ids While the SQL server and ABL database clients share the same _user table accounts, they use them differently. It is important to know what the differences are so that you do not open your application to security holes. Without _user accounts, the ABL default user-id is the OS process-id (for auditing purposes) and you cannot specify a user-id/password. SQL is the opposite, you can specify any user-id and password to set the user-id. The password is ignored. The built-in SQL server user-ids “PUB” and “SYSPROGRESS” are excluded. To get DBA rights you have to enter the name of the “database owner”. With _user accounts, the ABL will allow the anonymous blank user-id, where SQL server has no default user account. The default ABL behavior is to always allows an anonymous (blank user-id) account to execute the CONNECT statement. If you do specify user-id/password, they must match a _user account entry or you end up being the default blank user-id. SQL server will always require a valid user-id and password and will now accept the built-in user-ids “PUB” and “SYSPROGRESS”. DB-14: OpenEdge Database Run-time Security Revealed

ABL Prompting for User-id
It all happens inside ABL procedures : ABL Core: run _edit.p. _edit.p run _prostar.p. _prostar.p run _login.p. People will ask, the ABL will prompt for a user-id and password. Yes it does, but it does not require you to enter a user-id and password to connect to a database. All the ABL does when there is no start procedure and there is a database connected, is this sequence of procedures from whatever PROPATH is set to: Run edit.p from the $DLC/gui or $DLC/tty directory Edit.p runs prostar.p Prostar.p runs _login.p which contains the user interface All of these procedures, or their compiled r-code cousins must be in the PROPATH. But we give you the sources in the development kit and PSDN, so and you can change them to meet your own requirements. * Sources found in DLC/src & PSDN development tools download DB-14: OpenEdge Database Run-time Security Revealed

ABL & SQL User Account Administration
Similar user account operations : ABL SQL Create account CREATE _user record statement CREATE USER Delete account DELETE _user record statement DROP USER Change password ASSIGN field statement ALTER USER Create password ENCODE () N/A Managing the built-in user accounts via either ABL or SQL languages is very similar, except for one item. The ABL language allows someone to use the ENCODE function to manually manage _user account passwords. This is a perfect way to run a dictionary attack, so it lowers the effective security level for both the ABL and SQL. DB-14: OpenEdge Database Run-time Security Revealed

Alternative user authentication for ABL only applications : SQL Server ABL Core CLIENT- PRINCIPAL user authentication ABL Application user login credentials Proof of ABL user authentication user accounts ( _user )‏ user authentication ABL Core Authentication Configuration is valid? Validate CLIENT- PRINCIPAL is valid? Both the ABL & SQL use a standard authentication/authorization mechanism to the _user table accounts. The ABL language also has a feature, implemented during release 10.1A, that the SQL server does not, which is to allow the application code to assert a user identity that itself has authenticated to OpenEdge. The binding of the application’s user authentication and OpenEdge is through an authentication-token contained in the CLIENT-PRINCIPAL object. OpenEdge will validate the origination rights of the CLIENT-PRINCIPAL creator based on some configuration information contained in the OpenEdge database. The ABL CLIENT-PRINCIPAL system handle gives the ABL application code the same functionality as SET-USERID() in being able to control the user-id of the database connection. All without the need for using any of the built-in _User accounts. There is a whole session on this capability in “DB19: Authentication without the _User table”, so this session will not go into detail. Assume that what I talk about setting an ABL user-id I include both the CLIENT-PRINCIPAL and _user account methods. Y connection user-id A DB-14: OpenEdge Database Run-time Security Revealed

User Authorization DB-14: OpenEdge Database Run-time Security Revealed

All Tables Have an Owner
Both ABL & SQL clients respect table “ownership” : “PUB” (SQL server & ABL user-id) Data tables ABL clients: Create, Read, Update, & Delete SQL clients: Insert, Select, Update, & Delete Meta schema tables SQL clients: Select “SYSPROGRESS” (private user-id for SQL server) ABL clients: none “<sql-client>” (supported only by SQL server) ABL clients: none No security system is without the concept of table & column “ownership” , and the OpenEdge database is no exception. Built into the OpenEdge database is three “owners”: . “PUB” (for PUBLIC) owns all of the tables and fields that are equally accessible by both the ABL and SQL languages . “SYSPROGRESS” owns all of the tables and fields that are unique to the SQL server component . “sql-client” is the owner of tables and columns accessible only by SQL clients You will see how and why this “ownership” is important later on. DB-14: OpenEdge Database Run-time Security Revealed

ABL Core Database Security
Administered via _schema record CRUD operations : assign _Can- read _Can- write _Field record Permissions F1 F2 F3 F4 F5 F6 F7 find for create delete _Can- create _Can- write _Can- read _Can- delete _File Permissions The ABL core performs Record access control by using fields in the _file table that start with “Can-”. These are commonly referred to as the “Can-permissions”. The field names are: _Can-read (FIND, GET, etc)‏ _Can-write (Update)‏ _Can-create (CREATE)‏ _Can-delete (DELETE)‏ Primary-key: _File-name The ABL core performs Field level access controls using two “_Can-” permission fields in each fields definition in the _field table records. _Can-read (?)‏ _Can-write (ASSIGN)‏ Primary-key: _File-recid/_Field-name Table Data * Sometimes meta-schema table & field permissions lie DB-14: OpenEdge Database Run-time Security Revealed

SQL Server Database Security
Administered via GRANT/REVOKE SQL statements : Selective column update only alter update _syscolauth Privileges F1 F2 F3 F4 F5 F6 F7 select insert update delete insert update select delete _systabauth Privileges The SQL server uses “privileges” for table and columns. I’ve provided the table name of where they are stored for reference, but you can only control them through SQL language statements. For record level controls you have insert, update, select, and delete privileges that directly relate to the SQL INSERT, UPDATE, SELECT, and DELETE statements. At the field level, SQL only gives you the ability to control selective column UPDATE statements. What about READ access to selective columns? Table Data DB-14: OpenEdge Database Run-time Security Revealed

SQL Server Database Security
Wrapper for a mixture of selected rows & columns : alter update No read access by exclusion _syscolauth Privileges update update F1 F2 F3 F4 F5 F6 F7 select insert update delete create update read delete _systabauth Privileges insert update select delete Selective column read access is controlled through SQL views. A view is simply a wrapper that includes selected tables and columns into a named resource and gives you the ability to control individual privileges for those tables and columns. Table Data View Privileges DB-14: OpenEdge Database Run-time Security Revealed

Database Administration
DB-14: OpenEdge Database Run-time Security Revealed

SQL Standard Database Administration
DBA has all database privileges* Table’s “owner” has all table & column privileges A user must have a privilege before they can GRANT that privilege to others The grantor of a privilege can REVOKE that privilege A privilege may be GRANTED without the ability to grant it to any other user It should be no surprise that the OpenEdge SQL server implements the typical DBA administrator role. A table’s “owner” has full table column and view privileges. Only DBAs can control DBA privileges. And privileges can be granted by any grantee, providing the grantor of the privilege can, and does, pass along the ability to give it to another user. The notable exception is that the OpenEdge SQL DBA surrenders some of their privileges to auditing policies and data. We have another session that will help in this specific area: “DB08: Jump-starting your OpenEdge Auditing Solution”. * Except OpenEdge Auditing SoD (Separation of Duty) DB-14: OpenEdge Database Run-time Security Revealed

ABL Security Administrator Revealed
ABL Security Administrator is NOT A DBA ABL Security Administrator controls Table & field access via _Can-* permissions User account‏ creation & deletion ABL client & database security options Security Administrator’s user-account list is replicated in many places See PSDN open-source development tools src/prodict/user/_usradmn.p In contrast, the ABL core: . Does not have the concept of a DBA, you only get the equivalent of a SQL DBA if you configure and manage it yourself. . It does have a Security Administrator who can control the built-in user accounts and access controls (permissions) to tables and fields. . The strange thing is that the list Security Administrators is replicated in many “Can-*” fields throughout the database. The replication is both good, as you can delegate specific security operations to different sets of user, and bad because you can compromise the database by allowing different sets of users control over different parts of the database. See the bonus information slide at the end of the presentation to see the ABL code used to replicate the System Administrator’s list. DB-14: OpenEdge Database Run-time Security Revealed

OpenEdge 10 database security Comparing run-time and compile-time Configuring run-time database security DB-14: OpenEdge Database Run-time Security Revealed

Compile-time Versus Run-time Security
Lower Higher Security risk from user impersonation & rogue r-code No Yes Application security context > compile time < run-time Run-time impact Dynamic Fixed Table & column access Connection’s user-id Run-time Compile-time OpenEdge for years has promoted “compile-time” application security, and here this session is promoting “run-time” database security. This session’s point is that you have a choice, based on your belief that someone could connect to the database using their own application r-code (i.e. rogue r-code). When we compare the two models, three things stand out: With run-time security, the database run-time checks all r-code access to data. Not just for the user-id & permissions that were set when the r-code was compiled With run-time checking, the database has more work to do so there will be slightly With run-time checking, the risk from user impersonation or rogue r-code modules is less DB-14: OpenEdge Database Run-time Security Revealed

ABL .r-code contains only the permitted CRUD operations : user login credentials .p source (CRUD)‏ ABL Core compiler OE Database Server user accounts ( _user )‏ All record operations dynamic buffer user authentication (CRUD) static buffer connection user-id (RU) Permissions To put this into perspective, when you compile your ABL source code: R-code does not contain any user or permission information, it only contains the permitted compile-time operations All dynamic buffer operations are passed through to the r-code because you can’t check anything that changes at run-time All static buffer operations put the record operations permitted for the current database connection user-id into the r-code So in the diagram, all dynamic buffer operations are recorded in the r-code, but the static buffer permissions only allow Read/Update. Therefore only the Read & Update operations are recorded into the r-code. user access? .r code (RU)‏ Public Data (RU) Checks user-id to permitted operations Permitted record operations DB-14: OpenEdge Database Run-time Security Revealed

Default ABL Core run-time permission checking : user login credentials ABL Core run-time OE Database Server user accounts ( _user )‏ user authentication .r code (RU)‏ Checked at run-time connection user-id Permissions At run-time the ABL core executes all r-code record operations without exception. Internally, when the ABL core executes dynamic buffer operations it checks the current database connection’s user-id against the current table & field permissions, every time the r-code executes. All static buffer operations are passed straight through, assuming that what was not permitted has been filtered out. This is the model for compile-and-run from source code, and works very well because you essentially get run-time permission checking. The problem exists when someone can compile r-code against a copy of the database schema with full permissions. Copy that (rogue) r-code onto any system that can execute it and you have direct access to the data. (How do they get that schema information? How about a boot-strap piece of r-code that reads and dumps the schema information or just running the data dictionary’s r-code in the default PROPATH. ) user access? .r code (CRUD)‏ dynamic buffer Public Data static buffer Not checked at run-time DB-14: OpenEdge Database Run-time Security Revealed

ABL Core with optional run-time permission checking : user login credentials ABL Core run-time OE Database Server user accounts ( _user )‏ user authentication .r code (RU)‏ connection user-id Permissions Because of the inherent danger in the ABL core running any compiled r-code module, in OpenEdge release 10.1A we added the option to turn-on ABL run-time permission checking for static buffer operations. When this option is enabled, the run-time now forces all record/field operations through the user-id and permission checking each time any r-code is executed. In this way, rogue r-code is defeated because it can no longer bypass who the user-id is and what that user-id is authorized to do. With this option, all dynamic and static buffer operations have exactly the same physical access to the OpenEdge database. At this point, it’s your confidence in the production site running your application to never allow the execution of [rogue] r-code modules that are not contained in your application. (See the CSI/FBI numbers on internal unauthorized data access) user access? .r code (CRUD)‏ dynamic buffer Public Data static buffer All operations checked at run-time DB-14: OpenEdge Database Run-time Security Revealed

Agenda Run-time database security landscape OpenEdge database security
Comparing run-time and compile-time Configuring run-time database security DB-14: OpenEdge Database Run-time Security Revealed

Configuring Database Security
The best database security comes from multiple layers : ABL & SQL application security (Adds contextual application security to the database’s built-in security features) OpenEdge database run-time security (Protects database from rogue application- code and users) OS file system permissions (Protects database’s utilities, configuration, and data files from other OS processes) The best approach is obviously a balance of OS, application, and OpenEdge run-time security. I assume that you understand OS and application security well enough this session does not have to cover those topics. DB-14: OpenEdge Database Run-time Security Revealed

OpenEdge Database Security Options
Many security options available to fit your application : Database administration Database user connection Table & column/field access Database auditing OpenEdge provides a number of security options in four categories: Locking down who can perform database administration Who can connect to the database Who can read and/or change schema definitions Who can perform table and column operations at run-time Who has changed the accessibility to the database and what was it changed to DB-14: OpenEdge Database Run-time Security Revealed

Security Starts with User Accounts
When are database user accounts required ? A place to start “Database contain private or confidential data?” YES: I should configure database user accounts 1 or more _user administrator accounts 1 or more _user accounts for data access Eliminate built-in default-user accounts “_user accounts required for individual users?” If SQL server is used: YES If SQL is not used: can use application’s user accounts via the CLIENT-PRINCIPAL object Whenever you start talking about data security, you have to talk about user accounts. With all the regulations and standards, I find a grey-area between not allowing authenticated database connections and not allowing unrestricted access to the data. Most of the time I see SQL assumed, where you have to authenticate to a database user account before you get a connection. DB-14: OpenEdge Database Run-time Security Revealed

Database Administration Security Steps
If SQL Server installed, configure it’s DBA security first : Connect SQL explorer as any user-id and find the database’s “db-owner” SELECT * from SYSPROGRESS.SYSDBAUTH; It is the user-id that is not “SYSPROGRESS” Reconnect SQL explorer with the “db-owner” user-id Create a common ABL/SQL DBA account CREATE USER ‘MYDBA’, ‘dba-pwd’; GRANT RESOURCE, DBA to MYDBA; If SQL server is part of your application, or will be, I would suggest that you take care of the SQL DBA configuration first. All you have to do is create the first user account with the ABL data administration tool and you have NO SQL DBA. Taking care of this definition now will make it easier to migrate later and you don’t have to call OpenEdge and get tech support to tell you how to hack in as a SQL DBA. You first obtain who the “database owner” is from the SQL SYSPROGRESS.SYSDBAUTH table. It’s the record that is not “SYSPROGRESS”. Then connect to SQL using the database owner’s user-id, with a blank password. Then create a new account for a common SQL & ABL administrator (“mydba”) and then grant them DBA and RESOURCE privileges. DB-14: OpenEdge Database Run-time Security Revealed

Lockout built-in SQL DBAs & table owners : Connect SQL Explorer as MYDBA Create user accounts with known passwords CREATE USER ‘SYSPROGRESS’, ‘pwd’; CREATE USER ‘<db-owner>’, ‘pwd’; CREATE USER ‘PUB’, ‘pwd’; Next, I lockout the built-in OpenEdge user account references. That way nobody can use them as a back-door later in your database’s life. Simply connect as the new DBA and create user accounts for: “SYSPROGRESS”, the database owner, and “PUB”. If you want to lock those accounts out forever, then choose a random password. Otherwise you can keep the passwords secret until needed to recover from locking out your new DBA. DB-14: OpenEdge Database Run-time Security Revealed

Define ABL Security Administrator : Use Data Administration tool to deny PUBLIC Security Administrator access Define common ABL [ & SQL] administration user account [“MYDBA”] Admin->Security->Edit User list… Set the security administrator list to “MYDBA” * Admin->Security->Security Administrators… After SQL is taken care of, configure the ABL. I suggest you always make a security administrator account and block PUBLIC ability to change your database’s security. I would use the common DBA user and then use the Data Administration tool’s security menu to set the Security Administrator list. Setting it to “MYDBA” will exclude PUBLIC access. * Best practices indicate two user accounts defined DB-14: OpenEdge Database Run-time Security Revealed

Database Schema Administration
ABL client cannot change SQL user privileges SQL client cannot change ABL user permissions Define your own ABL-DBA by granting Grant PUBLIC (“*”) to _File._Can-read Grant _Can-create, _Can-write, _Can-delete to ABL Security Administrator account list for schema security “_File._File” “_File._sec-role” “_File._Field” “_File._sec-granted-role” “_File._Index” “_File._sec-authentication-domain “_File._Index-field” “_File._sec-authentication-system The next option available to you is to lock-down the database’s schema. First, in OpenEdge an ABL client cannot change any tables owned by SQL’s SYSPROGRESS. So your SQL server is protected against ABL application code. Likewise, SQL server will not allow a SQL application to directly change the database’s schema, and therefore the ABL permissions that it contains. Now SQL is not allowed to be a back-door to ABL access. Just a thought, I use a tools that emulates an ABL DBA so that the database’s schema definition is protected. I start with the list of where the ABL Security Administrator account list is replicated and add the these locations: _Can-create, _Can-write, and _Can-delete permissions of the _file (tables), _field (fields), _index (index), and _index-field (index-fields). It’s pretty easy and gives me like ABL and SQL DBA security. DB-14: OpenEdge Database Run-time Security Revealed

Enable Advanced ABL Security Features
Update to release 10.1A+ If not creating a new 10.1B+ database, update security schema definitions $ proutil db –C updateschema OR enable OpenEdge auditing $ prostrct add db audit-areas.st $ proutil db –C enableauditing area data-area-name indexarea index-area-name [disableindexes] To get any of the advanced database security features, you have to upgrade to 10.1A (service pack 2). Then you either enable OpenEdge auditing or run the “updateschmea” utility to add the necessary schema definitions. If you are creating a new 10.1B database, the schema definitions are already there. The tables are: _sec-db-option _sec-db-detail _sec-role _sec-granted-role _sec-authentication-system _sec-authentication-domain DB-14: OpenEdge Database Run-time Security Revealed

ABL Connection Security
Optionally block blank-user id connections Database Administration utility’s menu Admin->Database Options … Disallow Blank UserID* (*Requires 1 _user account & -U/-P connection) Pick your ABL access-control design All database connections use the user’s login id Application connects to the database using A single database user-id (1 user w. all permissions for all data tables) A role or group account (each application user-id has exactly 1 role ) You have the option of configuring the OpenEdge database to block a blank user-id from connecting to the database. Do no confuse this with the old option of blocking blank user-id authorization and allowed the open database connection to exist (and be exploited). This option will not allow the ABL client from getting to the point of holding an open database connection. Then pick the access-control model that best fits your database’s needs. Impersonation, where the application always connects as the end-user, is good for applications that use auditing of user-ids or you need to configure specific SQL access controls. Delegation model is where your application code connects as the database’s user-id and the database “delegates” some run-time security checking to the application code. Just as a thought, have your application connect to the database using a “no-access” user account. One that has no access to the database. This gives you the effect of blocking the blank user-id, but will allow an auditing solution to not have to deal with ambiguous “” blank user names. Once your application has done its job to authenticate the user, then reset the database’s connection to a user-account that has full data access. Now you have only 3 accounts to manage in the database: the dba, the no-access user, and the full access user. DB-14: OpenEdge Database Run-time Security Revealed

Binding R-code to the OpenEdge Database
DBAUTHKEY in case run-time security not achievable : Low level security option, but viable for some use- cases Simple secret-key hash value Embedded in database Compiled into r-code Checked by ABL core at run-time Not recommended where: ABL is customized at production site Database’s used in multiple applications Update application with subset of .r-code modules There is another security feature that isn’t talked about a lot. It does work and is useful in the right situations. The DBAUTHKEY/RCODEKEY utilities set a “shared-secret” password into the database and r-code modules. It allows you to tightly bind r-code modules to the database(s) that their record & field operations executed. It blocks rogue r-code modules by having an ABL client check the database connection and detect whether a DBAUTHKEY secret is set. If one is set, it checks the r-code modules to see that they contains the same secret before allowing their execution. This is a very simple secret-key hash code so it does not produce a robust solution and can be hard to setup and manage according to some of the feedback I get. This is yet another option for your consideration, it may be just right for your applications. DB-14: OpenEdge Database Run-time Security Revealed

Two ABL Permissions Security Strategies
Choose which suits your application the best : Use the application development defaults On [schema] tables where data is PUBLIC Deny user access to tables with restricted data * Deny default blank user-id access to all tables & fields Admin->Security->Disallow Blank Userid Access … Use the industry recommended GRANT model If your application uses SQL server security Tables that contain restricted-access tables or fields Default table/field access is System Administrators Add (grant) & remove (revoke) selective user accounts When working with run-time permissions in the ABL you have two paths open to you: Continue to use the application development defaults Use the industry recommended GRANT model. The goal here is to provide only the level of protection necessary to meet the security requirements. Most times those requirements say to “not allow access to unauthorized users”. They don’t specify how you do that, just that you do. For public data, I’d let the application defaults apply, but deny the blank user-id all access. The equivalent in SQL would be to explicitly GRANT PUBLIC privileges to all of the table privileges. For tables that contain confidential/private data, use the industry recommended GRANT model. Why: It will match the SQL server’s security model, so that when you do use SQL it will make it easier to keep both in sync. Especially where they both share the same user accounts. If an administrator makes a mistake, the default is no-access so you have not surrendered information inappropriately Make the table default permissions the ABL System Administrator list, this will now help you keep the SQL DBA and ABL Security Administrators in sync Then simply add an account to grant it access or remove the account to revoke its access * Not an recommended security practice DB-14: OpenEdge Database Run-time Security Revealed

ABL Run-time Database Security
Enabling ABL run-time permission checking : Turn on run-time checking via the data administration tool’s dialog Admin->Database Options … Use Runtime Permissions Checking Update application’s code error checking (if required) Tip: use ABL CAN-DO() to test permission list find _File where _File._File-Name = “Customer”. if CAN-DO(_File._Can-Delete, user_id) then DELETE Customer. The master switch to turning on the OpenEdge run-time permission checking is done via a simple check-box in the Data Administration utility’s “Database Options” dialog. In migrating your application to use run-time permission checking, you might get an access error where your application code does not expect it. It would be advisable to review and test your code and fix any problems you might find. DB-14: OpenEdge Database Run-time Security Revealed

Controlling Run-time Permission Checking
If permission denied, raises STOP event Enclose statement in a block with ON STOP DO ON STOP UNDO , LEAVE : FIND customer WHERE CustNum = m_iCustNum NO-ERROR. END. IF ( ERROR-STATUS:ERROR AND INDEX(ERROR-STATUS:GET-MESSAGE(1), “permission denied”) <> 0) THEN RETURN ERROR “Customer table read access denied”. … DB-14: OpenEdge Database Run-time Security Revealed

ABL Permission Secrets
Three Security Administrator rules you never forget : A Security Administrator is NOT treated special Table access Field access Granting/revoking other Security Administrators Each _Can-* permission field must have one of One Security Administrator account PUBLIC (“*”) Never, never, never leave a _Can-* permission list blank Some tips on keeping yourself out of trouble with ABL permissions. The ABL Security Administrator is not treated special, it has no built-in abilities. If an Security Administrator is not in a Can-* Permission list, you loose control (permanently). So always ensure that a minimum of one Security Administrator exists in all Can-* permission lists. Never allow a _Can-* permission to have a blank list. The ABL core will gladly lock you out!! DB-14: OpenEdge Database Run-time Security Revealed

ABL Permission Secrets
ABL _Can-* permission list rules : Order dependent, comma separated list of account names (no white-space!) Add account name to grant access, remove account names to revoke access Use “!” to explicitly deny access to an account Use “*” for wild-card multiple user account match PUBLIC access (all accounts) Can use “xxx_*” or “*_xxxx” for account names with the same prefix or suffix Things they don’t tell you about ABL Can-* permission lists: They are order dependent, the first connection user-id to Permission list name matches! You simple add names to grant permission and remove the name to revoke permissions. You can use the “!” to explicitly deny access to a user account or PUBLIC (“*”). You can use wildcards in matching multiple user account names if you use prefixes or suffixes to imply a role or group membership. DB-14: OpenEdge Database Run-time Security Revealed

ABL Permission List Examples
Illegal, nobody has access!!! Deny blank user grant access to no accounts “!” Deny blank user & fred, grant access to all other accounts “!,!fred,*” Grant access to blank user-id and all accounts “*” Pure GRANT model (denies blank user-id) “fred,wilma,MYDBA” Grant any account starting with “dba_” “barney,dba_*,MYDBA” List denied user accounts first SQL equivalent PUBLIC access SQL equivalent GRANT model Here are some examples of Permission lists. Interesting use of account name groups * More examples in Bonus slides DB-14: OpenEdge Database Run-time Security Revealed

ABL Permission Combinations
ABL permissions enforced at lower-level : FIND, GET, FOR-EACH type statements _File._Can-Read EQ, GT, LT, … field access _File._Can-Read, _Field._Can-Read CREATE record statement _File._Can-Read, _File._Can-Create, _File._Can-Write, _Field._Can-Write (required fields) ASSIGN record field values _File._Can-Read, _File._Can-Write, _Field._Can-Write DELETE record statement _File._Can-Read, _File._Can-Delete Where SQL privileges work at the language statement level and are very straight-forward, the ABL’s permissions work at the raw record & field access level. The OpenEdge tools make it appear simple to set the privileges, but that is not the case. The ABL actually requires combinations of permissions to get the same type of security access as SQL provides. On this slide I’ve recorded the combinations that I’ve found give me the expected CREATE, READ, UPDATE, & DELETE security. The foundation of any ABL operation is reading a record from the storage engine. You will find that for any CRUD permission control you will need to grant the user READ permission to the record. Most of the time you will want to grant PUBLIC read to table records, then deny only those fields that contain private/confidential data. After you’ve read the record into a buffer and you want to use field information, you then need to add READ (_Can-Read) permission on selective private/confidential fields. For non-private fields, PUBLIC access can be used. To CREATE a new database record and assign its values, you need to be able to both CREATE and ASSIGN. So grant Read, Create, & Write permission to the table. For restricted fields you selectively grant Write (_Can-Write) permission. To ASSIGN or change a field’s value, you’ll first need to read the record, then Write the field (_Can-Write), then Write the changed record back to the database. To DELETE records, you’ll first need to read the record and then have the Delete permission to remove it. DB-14: OpenEdge Database Run-time Security Revealed

Keeping SQL and ABL in Sync
Similar user access controls to PUB tables & columns : SQL ABL View INSERT SELECT UPDATE DELETE N/A Table INSERT SELECT UPDATE DELETE _Can-create _Can-read _Can-write _Can-delete When your application includes both SQL and ABL components, you may be required to keep the two security systems in sync. For many of the access controls there are equivalent access-controls. This simple table shows those equivalencies. Note that the ABL has new equivalent for a SQL “view”, and in SQL you can use a “view” to get the same results as you get with ABL field access. Column/field (view) UPDATE _Can-read _Can-write DB-14: OpenEdge Database Run-time Security Revealed

Privilege & Permission WARNING!
Beware of orphan privileges and permissions: Grant/revoke operations do not check account name presence Account’s SQL privileges & ABL permissions are NOT removed when account is deleted (including DBA & Security Administrator) If new account created with same name, it inherits all the old account’s privileges & permissions (also can be used as a recovery tool) A couple of notes on Permissions and Privileges: You can add an account name that does not exist. For support of external user accounts from an ABL application or other trusted source, the account name is not verified You can remove accounts without having their privileges removed. This again goes towards using user account systems outside of the OpenEdge database where accounts may come and go without OpenEdge’s knowledge DB-14: OpenEdge Database Run-time Security Revealed

In Summary More pressures to include database run-time security as intrusions become more sophisticated OpenEdge has added additional security features OpenEdge RDBMS can meet your database’s run-time security needs DB-14: OpenEdge Database Run-time Security Revealed

For More Information, go to…
PSDN OpenEdge SQL Authorization Documentation: OpenEdge Database Management: Database Administration OpenEdge Database Management: SQL Reference OpenEdge Development Collection: Progress 4GL Referenced DB-14: OpenEdge Database Run-time Security Revealed

Relevant Exchange Sessions
DEV-4: OpenEdge in an LDAP World COMP-7: Securing your Swiss Cheese Environment DEV-8: A statefull application in a stateless world DB-8: Jump-starting Your OpenEdge Auditing Solution DB-19: OpenEdge Authentication without the _User table DB-14: OpenEdge Database Run-time Security Revealed

Questions? DB-14: OpenEdge Database Run-time Security Revealed

Thank you for your time DB-14: OpenEdge Database Run-time Security Revealed

Bonus ABL Permission List Examples
Table “lock-out”, dump & load to recover “” Deny fred, grant access to all other accounts “!fred,fred,*” Grant access to fred and all accounts “fred,!fred,*” Pure GRANT model (denies blank user-id) “fred,wilma,MYDBA” Grant model, deny PUBLIC access “fred,wilma,MYDBA,!*” Grant model, grant blank user- id as middle account “fred,,wilma,MYDBA” Grant model, grant blank user- id as first account “,fred,wilma,MYDBA” Here are some examples of Permission lists. DB-14: OpenEdge Database Run-time Security Revealed

DB-14: OpenEdge® Database Run-time Security Revealed

Similar presentations

Presentation on theme: "DB-14: OpenEdge® Database Run-time Security Revealed"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

DB-14: OpenEdge® Database Run-time Security Revealed

Similar presentations

Presentation on theme: "DB-14: OpenEdge® Database Run-time Security Revealed"— Presentation transcript:

Similar presentations

About project

Feedback