Transcript Security

DB-14: OpenEdge® Database Run-time
Security Revealed
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
2
DB-14: OpenEdge Database Run-time Security Revealed
© 2007 Progress Software Corporation
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
3
DB-14: OpenEdge Database Run-time Security Revealed
© 2007 Progress Software Corporation
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
4
DB-14: OpenEdge Database Run-time Security Revealed
© 2007 Progress Software Corporation
Database Security
In a perfect world, the application stack has no security holes:
(Black-hat
hacker)
OS/Network Security
Application Application Application
A
B
C
xDBC Driver xDBC Driver xDBC Driver
DB Server
Database Utilities
(cache files)
RDBMS
(index blocks)
5
OS Files
DB-14: OpenEdge Database Run-time Security Revealed
(record blocks)
© 2007 Progress Software Corporation
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
DB Server
Database Utilities
(cache files)
RDBMS
(index blocks)
6
OS Files
DB-14: OpenEdge Database Run-time Security Revealed
(record blocks)
© 2007 Progress Software Corporation
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
7
DB-14: OpenEdge Database Run-time Security Revealed
© 2007 Progress Software Corporation
Agenda
 Run-time database security landscape
 OpenEdge 10 database security
 Comparing run-time and compile-time
 Configuring run-time database security
8
DB-14: OpenEdge Database Run-time Security Revealed
© 2007 Progress Software Corporation
OpenEdge Database Security
One database – two security systems :
SQL Server
ABL Core
application
ISUD
user
authentication
user
authentication
user
authorization
OpenEdge RDBMS
• Database storage
engine performs no
security operations
application
CRUD
user
authorization
user accounts
SQL Privileges
• SQL & ABL
clients provide all
database security
ABL Permissions
Public Tables
SQL Tables
9
DB-14: OpenEdge Database Run-time Security Revealed
© 2007 Progress Software Corporation
Comparing ABL & SQL Security Systems
ABL
10
SQL
Security model
GRANT
GRANT
Default DBA
n/a
Default security
administrator
Default table access
“*”
<db-owner>
SYSPROGRESS
n/a
“*”
<none>
Default field access
“*”
<none>
DB-14: OpenEdge Database Run-time Security Revealed
© 2007 Progress Software Corporation
OpenEdge Database Auditing
How do you know the security systems have not been compromised ?
SQL Server
ABL Core
application
ISUD
user
authentication
user
authentication
user
authorization
OpenEdge RDBMS
• No SQL or ABL
database record
operations can
bypass auditing
application
CRUD
user
authorization
Audit Rules
policies.xml
Audit subsystem
Audit Data
Schema & data
Tables
11
DB-14: OpenEdge Database Run-time Security Revealed
© 2007 Progress Software Corporation
User Authentication
12
DB-14: OpenEdge Database Run-time Security Revealed
© 2007 Progress Software Corporation
Shared ABL & SQL User Accounts
_User table accounts :

Two required fields
• user-id
(_Userid)
– Maximum length:
– Illegal characters:
• password
12
< 32 or “#*,!@”
(_Password)
– ABL: Changed only by the account’s owner
– SQL: Changed by DBA or the account’s owner


Password field:
Beware of default SQL DBA account definitions
• <db-owner>
• SYSPROGRESS
• PUB
13
fixed-length CRC-16 hash
DB-14: OpenEdge Database Run-time Security Revealed
(DBA privileges)
(DBA privileges)
(table owner privileges)
© 2007 Progress Software Corporation
ABL & SQL _User Account Behavior
ABL
• Without _User accounts
– User-id: OS process id
– Cannot use –U –P to
connect
SQL
• Without _User accounts
– Default user-id: none
– Connect with any user-id
except
• “PUB”
• “SYSPROGRESS”
(passwords ignored)
• With _User accounts
– Default user-id: “”
– -U/-P must match _user
account
– Can always CONNECT
as default user-id
14
DB-14: OpenEdge Database Run-time Security Revealed
• With _User accounts
– Default user-id: none
– MUST authenticate to
_User account
– PUB & SYSPROGRESS
accepted as user-ids
© 2007 Progress Software Corporation
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.
* Sources found in DLC/src &
PSDN development tools download
15
DB-14: OpenEdge Database Run-time Security Revealed
© 2007 Progress Software Corporation
ABL & SQL User Account Administration
Similar user account operations :
ABL
Create account
Delete account
CREATE _user
CREATE USER
record statement
DELETE _user
DROP USER
record statement
ASSIGN field
ALTER USER
statement
Change
password
Create password ENCODE ()
16
SQL
DB-14: OpenEdge Database Run-time Security Revealed
N/A
© 2007 Progress Software Corporation
OpenEdge Database Security
Alternative user authentication for ABL only applications :
SQL Server
ABL Core
user login
credentials
user accounts
( _user )
user
authentication
is
valid?
Y
connection
user-id
user
authentication
CLIENTPRINCIPAL
Validate
CLIENTPRINCIPAL
is
valid?
ABL Application
Proof of
ABL user
authentication
ABL Core
Authentication
Configuration
A
17
DB-14: OpenEdge Database Run-time Security Revealed
© 2007 Progress Software Corporation
User Authorization
18
DB-14: OpenEdge Database Run-time Security Revealed
© 2007 Progress Software Corporation
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
– ABL clients: Create, Read, Update, & Delete
– SQL clients: Select

“SYSPROGRESS”
(private user-id for SQL server)
• ABL clients: none
• SQL clients:
Select

“<sql-client>”
• SQL clients:
• ABL clients:
19
(supported only by SQL server)
Insert, Select, Update, & Delete
none
DB-14: OpenEdge Database Run-time Security Revealed
© 2007 Progress Software Corporation
ABL Core Database Security
Administered via _schema record CRUD operations :
assign
_Canwrite
_Field record
Permissions
find
for
create
delete
F1
F2
F3
_Canread
F4
_File
Permissions
* Sometimes meta-schema
table & field permissions lie
20
DB-14: OpenEdge Database Run-time Security Revealed
F5
F6
_Cancreate
F7
_Canwrite
_Canread
_Candelete
Table Data
© 2007 Progress Software Corporation
SQL Server Database Security
Administered via GRANT/REVOKE SQL statements :
Selective
column
update only
alter
_syscolauth
Privileges
select
insert
update
delete
update
F1
F2
F3
update
F4
_systabauth
Privileges
F5
F6
insert
F7
update
select
delete
Table Data
21
DB-14: OpenEdge Database Run-time Security Revealed
© 2007 Progress Software Corporation
SQL Server Database Security
Wrapper for a mixture of selected rows & columns :
alter
_syscolauth
Privileges
select
insert
update
delete
update
F1
F2
F3
update
F4
_systabauth
Privileges
View
Privileges
22
No read
access by
exclusion
DB-14: OpenEdge Database Run-time Security Revealed
F5
F6
create
insert
F7
update
select
read
delete
Table Data
© 2007 Progress Software Corporation
Database Administration
23
DB-14: OpenEdge Database Run-time Security Revealed
© 2007 Progress Software Corporation
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
* Except OpenEdge Auditing SoD (Separation of Duty)
24
DB-14: OpenEdge Database Run-time Security Revealed
© 2007 Progress Software Corporation
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
25
DB-14: OpenEdge Database Run-time Security Revealed
© 2007 Progress Software Corporation
Agenda
 Run-time database security landscape
 OpenEdge 10 database security
 Comparing run-time and compile-time
 Configuring run-time database security
26
DB-14: OpenEdge Database Run-time Security Revealed
© 2007 Progress Software Corporation
Compile-time Versus Run-time Security
Compile-time
Connection’s user-id
Fixed
Dynamic
Table & column access
Fixed
Dynamic
Run-time impact
< run-time
> compile time
Yes
No
Higher
Lower
Application security
context
Security risk from
user impersonation &
rogue r-code
27
Run-time
DB-14: OpenEdge Database Run-time Security Revealed
© 2007 Progress Software Corporation
OpenEdge Database Security
ABL .r-code contains only the permitted CRUD operations :
user login
credentials
.p
source
(CRUD)
All record
operations
OE Database
Server
ABL Core
compiler
dynamic buffer
(CRUD)
static buffer
user
authentication
connection
user-id
user accounts
( _user )
(RU)
Permissions
.r
code
(RU)
user
access?
(RU)
Permitted record
operations
28
DB-14: OpenEdge Database Run-time Security Revealed
Public Data
Checks user-id to
permitted operations
© 2007 Progress Software Corporation
OpenEdge Database Security
Default ABL Core run-time permission checking :
user login
credentials
OE Database
Server
ABL Core
run-time
user
authentication
.r
code
(RU)
Checked
at run-time
user accounts
( _user )
connection
user-id
Permissions
.r
code
(CRUD)
dynamic buffer
user
access?
Public Data
static buffer
Not checked
at run-time
29
DB-14: OpenEdge Database Run-time Security Revealed
© 2007 Progress Software Corporation
OpenEdge Database Security
ABL Core with optional run-time permission checking :
user login
credentials
OE Database
Server
ABL Core
run-time
user
authentication
.r
code
(RU)
user accounts
( _user )
connection
user-id
Permissions
.r
code
(CRUD)
dynamic buffer
user
access?
Public Data
static buffer
All operations
checked at run-time
30
DB-14: OpenEdge Database Run-time Security Revealed
© 2007 Progress Software Corporation
Agenda
 Run-time database security landscape
 OpenEdge database security
 Comparing run-time and compile-time
 Configuring run-time database security
31
DB-14: OpenEdge Database Run-time Security Revealed
© 2007 Progress Software Corporation
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 applicationcode and users)
 OS file system permissions
(Protects database’s utilities, configuration,
and data files from other OS processes)
32
DB-14: OpenEdge Database Run-time Security Revealed
© 2007 Progress Software Corporation
OpenEdge Database Security Options
Many security options available to fit your application :
1.
2.
3.
4.
33
Database administration
Database user connection
Table & column/field access
Database auditing
DB-14: OpenEdge Database Run-time Security Revealed
© 2007 Progress Software Corporation
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
34
DB-14: OpenEdge Database Run-time Security Revealed
© 2007 Progress Software Corporation
Database Administration Security Steps
If SQL Server installed, configure it’s DBA security first :
1. Connect SQL explorer as any user-id and find the
database’s “db-owner”
SELECT * from SYSPROGRESS.SYSDBAUTH;
2. It is the user-id that is not “SYSPROGRESS”
3. Reconnect SQL explorer with the “db-owner” user-id
4. Create a common ABL/SQL DBA account
CREATE USER ‘MYDBA’, ‘dba-pwd’;
GRANT RESOURCE, DBA to MYDBA;
35
DB-14: OpenEdge Database Run-time Security Revealed
© 2007 Progress Software Corporation
Database Administration Security Steps
Lockout built-in SQL DBAs & table owners :
1. Connect SQL Explorer as MYDBA
2. Create user accounts with known passwords
CREATE USER ‘SYSPROGRESS’, ‘pwd’;
CREATE USER ‘<db-owner>’, ‘pwd’;
CREATE USER ‘PUB’, ‘pwd’;
36
DB-14: OpenEdge Database Run-time Security Revealed
© 2007 Progress Software Corporation
Database Administration Security Steps
Define ABL Security Administrator :

Use Data Administration tool to deny PUBLIC
Security Administrator access
1. Define common ABL [ & SQL] administration
user account [“MYDBA”]
Admin->Security->Edit User list…
2. Set the security administrator list to
“MYDBA” *
Admin->Security->Security Administrators…
* Best practices indicate two user accounts defined
37
DB-14: OpenEdge Database Run-time Security Revealed
© 2007 Progress Software Corporation
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._Field”
“_File._Index”
“_File._Index-field”
38
DB-14: OpenEdge Database Run-time Security Revealed
“_File._sec-role”
“_File._sec-granted-role”
“_File._sec-authentication-domain
“_File._sec-authentication-system
© 2007 Progress Software Corporation
Enable Advanced ABL Security Features
1.
2.
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]
39
DB-14: OpenEdge Database Run-time Security Revealed
© 2007 Progress Software Corporation
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 )
40
DB-14: OpenEdge Database Run-time Security Revealed
© 2007 Progress Software Corporation
Binding R-code to the OpenEdge Database
DBAUTHKEY in case run-time security not achievable :

Low level security option, but viable for some usecases

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
41
DB-14: OpenEdge Database Run-time Security Revealed
© 2007 Progress Software Corporation
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
* Not an recommended security practice
42
DB-14: OpenEdge Database Run-time Security Revealed
© 2007 Progress Software Corporation
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.
43
DB-14: OpenEdge Database Run-time Security Revealed
© 2007 Progress Software Corporation
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”.
…
44
DB-14: OpenEdge Database Run-time Security Revealed
© 2007 Progress Software Corporation
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
45
DB-14: OpenEdge Database Run-time Security Revealed
© 2007 Progress Software Corporation
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
46
DB-14: OpenEdge Database Run-time Security Revealed
© 2007 Progress Software Corporation
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
Grant access to blank user-id
and all accounts
Pure GRANT model
(denies blank user-id)
Grant any account
starting with “dba_”
“!”
“!,!fred,*”
“*”
List denied
user accounts
first
SQL equivalent
PUBLIC access
“fred,wilma,MYDBA”
SQL equivalent
GRANT model
“barney,dba_*,MYDBA”
Interesting use
of account
name groups
* More examples in Bonus slides
47
DB-14: OpenEdge Database Run-time Security Revealed
© 2007 Progress Software Corporation
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,

48
_Field._Can-Write
DELETE record statement
• _File._Can-Read, _File._Can-Delete
DB-14: OpenEdge Database Run-time Security Revealed
© 2007 Progress Software Corporation
Keeping SQL and ABL in Sync
Similar user access controls to PUB tables & columns :
SQL
49
View
INSERT
SELECT
UPDATE
DELETE
Table
INSERT
SELECT
UPDATE
DELETE
Column/field
(view)
UPDATE
DB-14: OpenEdge Database Run-time Security Revealed
ABL
N/A
_Can-create
_Can-read
_Can-write
_Can-delete
_Can-read
_Can-write
© 2007 Progress Software Corporation
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)
50
DB-14: OpenEdge Database Run-time Security Revealed
© 2007 Progress Software Corporation
In Summary
 More pressures to include


51
database run-time security
as intrusions become more
sophisticated
OpenEdge 10.1+ has added
additional security features
OpenEdge 10.1+ RDBMS
can meet your database’s
run-time security needs
DB-14: OpenEdge Database Run-time Security Revealed
© 2007 Progress Software Corporation
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
52
DB-14: OpenEdge Database Run-time Security Revealed
© 2007 Progress Software Corporation
Relevant Exchange Sessions
 DEV-4: OpenEdge in an LDAP World
 COMP-7: Securing your Swiss Cheese



53
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
© 2007 Progress Software Corporation
Questions?
54
DB-14: OpenEdge Database Run-time Security Revealed
© 2007 Progress Software Corporation
Thank you for
your time
55
DB-14: OpenEdge Database Run-time Security Revealed
© 2007 Progress Software Corporation
Bonus ABL Permission List Examples
56
Table “lock-out”, dump & load
to recover
Deny fred, grant access to all
other accounts
Grant access to fred and all
accounts
Pure GRANT model
(denies blank user-id)
Grant model, deny PUBLIC
access
“”
Grant model, grant blank userid as middle account
Grant model, grant blank userid as first account
“fred,,wilma,MYDBA”
DB-14: OpenEdge Database Run-time Security Revealed
“!fred,fred,*”
“fred,!fred,*”
“fred,wilma,MYDBA”
“fred,wilma,MYDBA,!*”
“,fred,wilma,MYDBA”
© 2007 Progress Software Corporation