Lifecycle Management of Rela1onal Records for External - - PowerPoint PPT Presentation

▶
lifecycle management of rela1onal records for external
SMART_READER_LITE
LIVE PREVIEW

Lifecycle Management of Rela1onal Records for External - - PowerPoint PPT Presentation

Aug 20, 2022 139 likes •418 views

Lifecycle Management of Rela1onal Records for External Audi1ng and Regulatory Compliance Ahmed Ataullah Frank Wm. Tompa Policies and Constraints

slide-1
SLIDE 1

Lifecycle ¡Management ¡ ¡of ¡Rela1onal ¡Records ¡ ¡for ¡External ¡Audi1ng ¡ ¡and ¡Regulatory ¡Compliance ¡

Ahmed ¡Ataullah ¡ Frank ¡Wm. ¡Tompa ¡

slide-2
SLIDE 2

Policies ¡and ¡Constraints ¡

§ What ¡is ¡a ¡business ¡policy? ¡

  • A ¡specifica1on ¡of ¡what ¡should ¡(or ¡should ¡not) ¡

happen ¡in ¡the ¡opera1ons ¡of ¡a ¡business. ¡

­ Typically ¡wriHen ¡in ¡natural ¡language ¡

§ Policies ¡manifest ¡themselves ¡in ¡database ¡

systems ¡as ¡constraints ¡or ¡alerts ¡

  • Check ¡constraints ¡
  • Transac1on ¡termina1on ¡triggers ¡
  • Access ¡control ¡restric1ons ¡

2

slide-3
SLIDE 3

Business ¡Model ¡

§ Means ¡of ¡simplifying ¡and ¡summarizing ¡a ¡set ¡of ¡

rules ¡ ¡

  • Provides ¡a ¡high-­‑level ¡overview ¡
  • Intermediate ¡layer ¡between ¡natural ¡language ¡and ¡

implementa1on ¡(code) ¡

  • Logical ¡or ¡graphical ¡

§ Types ¡of ¡modeling: ¡

  • Data ¡modeling: ¡ER, ¡UML, ¡… ¡
  • Process ¡modeling: ¡Workflow, ¡Flow-­‑chart, ¡PERT ¡charts, ¡… ¡
  • Policy ¡modeling: ¡Hierarchical ¡access ¡control ¡modeling, ¡

Object ¡Constraint ¡Language, ¡… ¡

3

slide-4
SLIDE 4

Database ¡System ¡Perspec1ve ¡

§ Database ¡reflects ¡enterprise ¡

  • Database ¡instance ¡≡ ¡overall ¡‘state ¡of ¡a ¡business’ ¡

§ Instance ¡must ¡comply ¡with ¡published ¡policy ¡

  • Database ¡system ¡must ¡con1nuously ¡monitor ¡

updates ¡to ¡ensure ¡compliance. ¡

  • Single ¡compliance ¡layer ¡eliminates ¡need ¡to ¡embed ¡

policy ¡checking ¡logic ¡in ¡every ¡applica1on ¡

  • Significantly ¡simplifies ¡implementa1on ¡of ¡complex ¡

data ¡constraints ¡

4

slide-5
SLIDE 5

Difficul1es ¡

§ Each ¡department ¡has ¡its ¡own ¡constraints ¡

  • Shared ¡database ¡⇒ ¡conflicts ¡can ¡be ¡detected ¡

beforehand ¡

  • Many ¡are ¡complex ¡(temporal, ¡condi1onal, ¡path ¡
  • riented) ¡

­ “A ¡student ¡can ¡take ¡CS446 ¡only ¡if ¡she ¡has ¡passed ¡CS330 ¡and ¡

CS245 ¡with ¡a ¡score ¡of ¡75% ¡or ¡more” ¡ ¡

­ Typically ¡correspond ¡to ¡complex ¡transac1on ¡termina1on ¡

triggers ¡

§ Many ¡constraints ¡derived ¡from ¡business ¡policies ¡

  • Scale ¡⇒ ¡manageability ¡a ¡major ¡problem ¡for ¡DB ¡

administrators ¡and ¡programmers ¡

5

slide-6
SLIDE 6

Why ¡have ¡exis1ng ¡models ¡failed ¡us? ¡

§ Complex ¡(temporal, ¡path) ¡constraints ¡difficult ¡to ¡model. ¡ ¡

  • “A ¡professor ¡cannot ¡teach ¡CS448 ¡and ¡CS490 ¡at ¡the ¡same ¡1me.” ¡
  • “A ¡professor ¡can ¡teach ¡CS348 ¡only ¡once ¡in ¡two ¡years.” ¡

§ No ¡no1on ¡of ¡policy-­‑relevant ¡object ¡ § State ¡of ¡an ¡“object” ¡is ¡sta1c ¡

  • Historical ¡applica1ons ¡are ¡“forgoHen” ¡
  • “Salary ¡of ¡an ¡employee ¡can ¡only ¡be ¡increased ¡three ¡1mes ¡in ¡any ¡
  • ne ¡year ¡period.” ¡

§ Inter-­‑rule ¡dependencies ¡cannot ¡be ¡expressed ¡

  • For ¡example: ¡“Rule ¡1 ¡should ¡only ¡be ¡enforced ¡if ¡Rule ¡2 ¡was ¡

never ¡violated ¡in ¡the ¡past ¡by ¡a ¡transac1on” ¡ ¡ ¡

6

slide-7
SLIDE 7

Avoiding ¡Hand-­‑wriHen ¡Triggers ¡

§ Can ¡we ¡make ¡the ¡task ¡of ¡the ¡programmer ¡easier? ¡ § Can ¡we ¡make ¡the ¡database ¡level ¡workflows ¡more ¡

transparent ¡to ¡business ¡level ¡managers? ¡

§ Can ¡we ¡introduce ¡policy-­‑to-­‑constraint ¡

transparency ¡and ¡manageability ¡and ¡offer ¡ compliance ¡guarantees ¡at ¡the ¡same ¡1me? ¡

7

slide-8
SLIDE 8

Step ¡1 ¡ Basic ¡Framework: ¡Objects ¡

§ Start ¡with ¡the ¡object ¡defini1ons ¡

  • An ¡object ¡defini1on ¡is ¡any ¡rela(onal ¡view ¡over ¡a ¡

fixed ¡database ¡schema. ¡

§ Object ¡= ¡tuple ¡(row) ¡in ¡such ¡a ¡view ¡

  • View ¡can ¡represent ¡a ¡complete ¡business ¡ar1fact ¡

­ All ¡data ¡needed ¡for ¡policy ¡making ¡

  • Assume ¡each ¡row ¡in ¡view ¡is ¡uniquely ¡iden1fiable ¡ ¡

8

slide-9
SLIDE 9

Step ¡2 ¡ Basic ¡Framework: ¡States ¡

§ State ¡S: ¡condi1on ¡on ¡objects ¡in ¡the ¡view ¡

defini1on ¡

  • Object ¡x ¡is ¡in ¡state ¡S ¡⇔ ¡its ¡aHributes ¡sa1sfy ¡S(x) ¡
  • Example ¡

­ EXPENSE_CLAIM_DETAILS ¡is ¡user-­‑defined ¡view ¡ ­ “Claim ¡objects” ¡are ¡rows ¡in ¡the ¡view ¡ ­ Object ¡O ¡(tuple ¡t) ¡is ¡in ¡state ¡P, ¡the ¡“paid ¡state”, ¡if ¡the ¡

condi1on ¡EXPENSE_CLAIM_DETAILS.PAID ¡= ¡TRUE ¡for ¡t ¡

§ An ¡object ¡can ¡be ¡in ¡mul1ple ¡states ¡at ¡once. ¡

¡ ¡ ¡

9

slide-10
SLIDE 10

Step ¡3: ¡Convert ¡business ¡model ¡into ¡ enforcement ¡model ¡

§ Rectangles ¡represent ¡business ¡states ¡ ¡ § Transi1ons ¡represent ¡processes/ac1ons ¡ § S1ck-­‑figures ¡represent ¡agents ¡ § Constraints ¡implied ¡by ¡absence ¡of ¡transi1ons ¡

  • E.g., ¡Paid ¡invoices ¡are ¡not ¡deleted ¡

10

Awaiting Approval Awaiting Payment Paid

New expense claim filed Reviewed by supervisor Reviewed by Finance Dept. Payment completed

slide-11
SLIDE 11

Business ¡states ¡and ¡DB ¡states ¡

§ States ¡of ¡an ¡object ¡are ¡typically ¡an ¡interpreta1on ¡

  • f ¡stages ¡in ¡business ¡process. ¡
  • Including ¡object ¡crea1on ¡and ¡destruc1on ¡

§ All ¡constraints ¡should ¡be ¡made ¡explicit. ¡

11

New expense claim filed Reviewed by supervisor Reviewed by Finance Dept. Payment completed

Awaiting Approval Awaiting Payment Paid

Φ

Awaiting Approval Approved = false AND Paid = false Paid Approved = true AND Paid = true Awaiting Payment Approved = true AND Paid = false

slide-12
SLIDE 12

Constraints ¡on ¡State ¡Transi1ons ¡

¬ ¡•B(x) ¡⋀ ¡B(x) ¡ ¡⇒ ¡ ¡• ¡A(x) ¡ ¡

12

A B A B A B

♦A(x) ¡⇒ ¡¬B(x) ¡ ¡

  • A(x) ¡⋀ ¡¬ ¡A(x) ¡ ¡⇒ ¡B(x) ¡ ¡

§ Define ¡various ¡types ¡of ¡constraint ¡ ¡

  • Use ¡past ¡temporal ¡logic ¡
  • Create ¡diagramma1c ¡form ¡

§ Special ¡interpreta1ons ¡for ¡transi1ons ¡to ¡or ¡from ¡Φ ¡

slide-13
SLIDE 13

Back ¡to ¡the ¡Example ¡

§ Convert ¡to ¡temporal ¡logic ¡ New(x) ¡ ¡ ¡⇒ ¡ ¡Awai1ngApp(x) ¡ ¬ ¡•Awai1ngPay(x) ¡⋀ ¡Awai1ngPay(x) ¡ ¡⇒ ¡ ¡• ¡Awai1ngApp(x) ¡ ¡ ¬ ¡•Paid(x) ¡⋀ ¡Paid(x) ¡ ¡⇒ ¡ ¡• ¡Awai1ngPay(x) ¡ ¡ Paid(x) ¡⇒ ¡Retain(x) ¡ § Test ¡these ¡condi1ons ¡in ¡the ¡database ¡

13

Φ

Awaiting Approval Approved = false AND Paid = false Paid Approved = true AND Paid = true Awaiting Payment Approved = true AND Paid = false

slide-14
SLIDE 14

State ¡Configura1on ¡of ¡an ¡Object ¡

14

Φ

Awaiting Approval Approved = false AND Paid = false Paid Approved = true AND Paid = true Awaiting Payment Approved = true AND Paid = false

§ States ¡= ¡{ ¡Awai1ngApproval, ¡ ¡

¡ ¡Awai1ngPayment, ¡ ¡ ¡Paid} ¡

§ State ¡space ¡= ¡{(0,0,0),(0,0,1),(0,1,0),…,(1,1,1)} ¡ § Some ¡configura1ons ¡are ¡not ¡sa1sfiable ¡

slide-15
SLIDE 15

Maintain ¡State ¡Configura1on ¡History ¡

§ A ¡complete, ¡temporally ¡ordered ¡list ¡of ¡state ¡

configura1ons ¡for ¡an ¡object ¡

15

Time ¡ Awai1ng ¡ Approval ¡ Awai1ng ¡ Payment ¡ Paid ¡ t1 ¡ 0 ¡ 0 ¡ 0 ¡ t2 ¡ 1 ¡ 0 ¡ 0 ¡ t3 ¡ 0 ¡ 1 ¡ 0 ¡ t4 ¡ 0 ¡ 0 ¡ 1 ¡

Object O1 history

slide-16
SLIDE 16

Implementa1on: ¡Tracking ¡the ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ State ¡Configura1on ¡History ¡

§ Every ¡1me ¡an ¡object ¡is ¡modified, ¡look ¡back ¡at ¡the ¡

history ¡and ¡answer ¡the ¡query ¡related ¡to ¡each ¡ constraint! ¡

16

Time ¡ Awai1ng ¡ Approval ¡ Awai1ng ¡ Payment ¡ Paid ¡ t1 ¡ 0 ¡ 0 ¡ 0 ¡ t2 ¡ 1 ¡ 0 ¡ 0 ¡ t3 ¡ 0 ¡ 1 ¡ 0 ¡ … ¡ … ¡ … ¡ … ¡ t_new ¡ 0 ¡ 0 ¡ 1 ¡

slide-17
SLIDE 17

Allow ¡Mul1ple ¡Constraint ¡Diagrams ¡

§ Model ¡business ¡processes ¡as ¡constraint ¡diagrams ¡ § Convert ¡to ¡temporal ¡logic ¡implemented ¡as ¡triggers ¡

¬ ¡∃x ¡∈ ¡R1 ¡: ¡♦Paid(x) ¡⋀ ¡UnderReview(x) ¡ ¬ ¡∃x ¡∈ ¡R1 ¡: ¡¬ ¡•Awai1ngPayment(x) ¡⋀ ¡Awai1ngPayment(x) ¡⋀ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¬ ¡• ¡UnderReview(x) ¡ ¡

17

R1: Awaiting Approval APPROVED = FALSE

∅

R1: Old (DATE_DIFF(NOW, PAID_DATE, years) >7) | (DATE_DIFF(NOW, CREATE_DATE, years) > 5 & PAID=FALSE)

∅

R1: Under Review APPROVED = FALSE R1: Awaiting Payment APPROVED = TRUE & PAID = FALSE R1: Paid PAID = TRUE

Data ¡ Entry ¡ Financial ¡Integrity ¡ Records ¡ Reten1on ¡

slide-18
SLIDE 18

Benefits: ¡Separa1on ¡of ¡Du1es ¡

§ Instead ¡of ¡a ¡single ¡large ¡complex ¡workflow ¡

18

§ Each ¡department, ¡person, ¡or ¡stakeholder ¡can ¡

independently ¡establish ¡state ¡oriented ¡path ¡ restric1ons ¡

slide-19
SLIDE 19

Mul1-­‑user ¡lifecycles ¡

¡ ¡ ¡

19

n Each ¡colour ¡represents ¡states ¡of ¡interest ¡for ¡

a ¡different ¡party ¡

slide-20
SLIDE 20

Allow ¡Complex ¡Path ¡Constraints ¡

§ E.g., ¡an ¡object ¡should ¡never ¡reach ¡state ¡C ¡if ¡it ¡has ¡

previously ¡transi1oned ¡from ¡A ¡to ¡B ¡

§ Constraint ¡1 ¡: ¡B(r) ¡⋀ ¡¬●B(r) ¡⇒●A(r) ¡ § Constraint ¡2 ¡: ¡♦1(x) ¡⇒ ¡¬C(x) ¡

♦(B(r) ¡⋀ ¡¬●B(r) ¡⇒●A(r)) ¡ ¡⇒ ¡¬C(x) ¡

20

1 A B C 2

slide-21
SLIDE 21

Summary ¡

§ Policy ¡designer ¡only ¡needs ¡to ¡list ¡the ¡“states ¡of ¡

interest” ¡ ¡

  • By ¡specifying ¡the ¡condi1ons ¡that ¡the ¡object ¡must ¡sa1sfy ¡

to ¡be ¡in ¡those ¡states ¡

  • Each ¡policy ¡designer ¡in ¡the ¡organiza1on ¡can ¡list ¡his/her ¡
  • wn ¡states ¡of ¡interest ¡

§ Policy ¡restricts ¡paths ¡that ¡an ¡objects ¡can ¡(or ¡

should) ¡traverse ¡ ¡

  • Constraint ¡diagram ¡(the ¡model) ¡

­ Some ¡paths ¡must ¡always ¡be ¡taken, ¡some ¡must ¡never ¡be ¡

traversed, ¡and ¡others ¡can ¡be ¡condi1onally ¡traversed ¡

  • Need ¡flexibility ¡in ¡specifying ¡constraints ¡

21

slide-22
SLIDE 22

Keep ¡DB ¡State ¡History ¡(audit) ¡

§ Define ¡business ¡records ¡as ¡database ¡views ¡

Invoice ¡= ¡(INV_ID, ¡CREATE_DATE, ¡PAID, ¡AMOUNT, ¡PAID_DATE, ¡APPROVED) ¡

  • PAST-­‑TL ¡constraint ¡is ¡a ¡restric1on ¡on ¡current ¡state ¡
  • f ¡a ¡view ¡given ¡its ¡history ¡

§ Augment ¡DB ¡audit ¡trail ¡with ¡state ¡vector ¡

xt= ¡(1mestamp,a1,a2, ¡…, ¡an, ¡user, ¡user_group, ¡purpose, ¡applica1on_context, ¡ transac1on_type, ¡txn_starwme, ¡…, ¡s1, ¡s2, ¡s3, ¡…, ¡sk) ¡

  • Check ¡all ¡constraints ¡on ¡newly ¡entered ¡states ¡

22

slide-23
SLIDE 23

Extending ¡the ¡model ¡

§ Define ¡addi1onal ¡transi1on ¡constraint ¡types ¡ § Include ¡temporal ¡access ¡control ¡

  • Use ¡transac1onal ¡meta ¡data ¡
  • E.g., ¡claim ¡can ¡only ¡be ¡approved ¡by ¡someone ¡in ¡the ¡

“management” ¡user ¡group ¡and ¡can ¡only ¡be ¡paid ¡by ¡someone ¡ in ¡the ¡“finance” ¡user ¡group ¡

23

Time ¡ A ¡ B ¡ C ¡ User_Group ¡= ¡Management ¡ User_Group ¡= ¡Finance ¡ t1 ¡ 0 ¡ 0 ¡ 0 ¡ 0 ¡ 0 ¡ t2 ¡ 1 ¡ 0 ¡ 0 ¡ 0 ¡ 0 ¡ t3 ¡ 0 ¡ 1 ¡ 0 ¡ 1 ¡ 0 ¡ … ¡ … ¡… ¡… ¡ 0 ¡ 1 ¡ t_new ¡ 0 ¡ 0 ¡ 1 ¡ … ¡ … ¡

slide-24
SLIDE 24

Performance ¡Analysis: ¡ Storage ¡Overhead ¡

§ Addi1onal ¡storage ¡space ¡required ¡to ¡store ¡the ¡

current ¡(extended) ¡state ¡configura1on ¡

§ 1 ¡bit ¡for ¡each ¡state ¡

  • 256 ¡states ¡= ¡32bytes ¡or ¡characters ¡

§ For ¡business ¡scenarios ¡where ¡large ¡text ¡fields ¡are ¡

logged, ¡the ¡addi1onal ¡overhead ¡will ¡be ¡minimal ¡

24

slide-25
SLIDE 25

Performance ¡Analysis: ¡ Computa1onal ¡Costs ¡

§ CPU ¡1me ¡spent ¡compu1ng ¡the ¡(extended) ¡state ¡

configura1on ¡history ¡

  • One ¡check ¡per ¡state ¡to ¡establish ¡membership ¡
  • Proper ¡nes1ng ¡of ¡these ¡checks ¡can ¡minimize ¡

computa1on ¡costs ¡

§ Cost ¡is ¡insignificant ¡compared ¡to ¡wri1ng ¡audit ¡

entry ¡onto ¡disk ¡

25

slide-26
SLIDE 26

Conclusions ¡and ¡Future ¡Work ¡

§ Bridge ¡between ¡business ¡policy ¡manager ¡and ¡database ¡

  • Constraint ¡diagram ¡makes ¡policy ¡statements ¡explicit ¡
  • Emphasizes ¡data ¡but ¡models ¡processes ¡and ¡user ¡interac1ons ¡
  • Allows ¡mul1ple ¡diagrams ¡and ¡mul1ple ¡concurrent ¡states ¡
  • Equivalent ¡to ¡past ¡temporal ¡logic ¡
  • Implementable ¡as ¡database ¡triggers ¡on ¡meaningful ¡views ¡
  • Experiments ¡show ¡that ¡extra ¡space ¡and ¡1me ¡to ¡check ¡constraints ¡is ¡

insignificant ¡overhead ¡on ¡audi1ng. ¡

§ Future ¡work ¡

  • Transla1ng ¡NLP ¡policies ¡into ¡constraint ¡diagrams ¡
  • Extrac1ng ¡workflows ¡from ¡database ¡transac1on ¡logs ¡

26