Informal database access lingered; ServiceNow with Privileged Access Management (PAM) enforced time?bound MFA sessions

Overview

A research lab granted database access informally through emails and shared credentials, which left long?lived privileges and unclear approval trails. Engineers added users to groups for convenience, emergency access lingered, and audits required manual reconstruction of who approved what. Intelligex implemented a request workflow tied to a Privileged Access Management (PAM) layer with time?bound grants, multifactor authentication (MFA), and session recording, plus periodic access reviews. Standing access receded, approval steps became visible and enforceable, and compliance checks drew on consistent evidence—while existing identity, ticketing, database platforms, and monitoring stayed in place.

Client Profile

• Industry: Scientific research and analytics
• Company size (range): Central IT supporting scientific computing and data teams with shared platform services
• Stage: Mix of on?premises and cloud databases; access granted via email threads and long?lived groups; limited auditing of session activity
• Department owner: IT & Infrastructure (Platform Engineering, DBA, and Security)
• Other stakeholders: Research and Data Science, Application Owners, Compliance/Audit, Legal/Privacy, Procurement, Service Desk, Identity and Access Management

The Challenge

Researchers and engineers reached databases through shared accounts or ad hoc additions to privileged groups. Approvals lived in emails, and grants did not expire, so access often outlived the original need. Contractors and visiting collaborators followed different paths, which left inconsistent records. When an incident required quick analysis, emergency access was enabled broadly and then forgotten. Session logging varied by platform, and pulling a complete story for an audit meant sifting through tickets, emails, and partial logs.

Support teams struggled with handoffs. DBAs wanted least?privilege accounts per task, Security needed session accountability, and service owners needed a way to approve access without blocking science. Database types and locations differed, and each team used slightly different patterns for credentials. The result was a reliance on people to remember expiry dates, revoke access, and collect evidence after the fact.

Constraints were real. Migration off existing identity or databases was not feasible. The lab needed a way to add request and approval rigor, make access ephemeral, and record activity without slowing research or re?platforming core systems.

Why It Was Happening

There was no single control plane connecting approvals to enforcement. Tickets captured intent, but database roles and credentials were provisioned manually and left in place. Shared passwords and group membership became the default because they were fast. Session logging was inconsistent across platforms, which meant investigations depended on manual correlation. Without time?bound grants and periodic reviews, risk accumulated quietly.

Ownership was fragmented. Identity managed accounts and MFA, DBAs granted roles, Security defined standards, and the Service Desk routed requests. With no governed workflow that combined all of these signals—approval, identity, posture, brokering, and recording—every exception became a custom path.

The Solution

Intelligex implemented a request?to?enforcement pipeline anchored on PAM. Database access was requested through the IT Service Management (ITSM) portal, routed to owners for approval, and fulfilled by the PAM platform as a time?bound grant with MFA and session recording. Users connected through brokered sessions or checked?out credentials that expired automatically. Sensitive operations required additional approvers, and periodic reviews validated ongoing need. The design leveraged a PAM platform such as CyberArk Privileged Access Manager for brokering and session recording, existing identity providers for MFA, ServiceNow for request and approval workflows (ServiceNow Docs), and identity governance for periodic reviews (for example, Microsoft Entra Access Reviews).

• Integrations: ITSM request and approval workflows; PAM vault for secrets and brokered sessions; identity provider for SSO and MFA; database connectors for PostgreSQL, SQL Server, and MySQL; SIEM for session metadata and alerts; data catalog for owner lookups where available.
• Access patterns: Just?in?time role grants; ephemeral credential checkout for service tasks; brokered sessions with keystroke or command?level recording; automatic revoke on expiry.
• Policies and approvals: Owner approvals based on database, environment, and data sensitivity; maker?checker for elevated roles; reason codes and evidence required; time?bound exceptions with compensating controls.
• Controls and validation: MFA enforced at session start; device and network posture checks where supported; command allow/deny lists for sensitive databases; alerts on unusual patterns routed to Security.
• Periodic reviews: Scheduled access reviews by owners and data stewards; non?responses removed automatically; outcomes logged with rationale and effective dates.
• Observability and evidence: Session metadata, recordings, approvals, and expiry captured and linked to tickets; dashboards for upcoming expirations, exception aging, and high?risk activity; exportable evidence packs for audits.
• Safety and privacy: Session recordings stored under restricted access; redaction patterns for sensitive values in logs; role?based permissions for vault and playback; retention aligned to policy.

Implementation

• Discovery: Cataloged databases, environments, and typical roles; mapped current request paths and email approvals; identified data classifications and sensitive operations; reviewed MFA capabilities and device posture signals; gathered audit requirements for session evidence and retention.
• Design: Authored the request catalog and approval matrices by database and environment; defined just?in?time role mappings; selected PAM connectors for each platform; designed session recording scope and redaction; outlined periodic review cadence and ownership; planned dashboards and evidence exports.
• Build: Integrated ITSM with PAM for request?to?grant automation; configured vaulting and brokered sessions; enabled MFA prompts and posture checks; set up role templates and expiry policies; wired SIEM for session metadata and alerts; configured access reviews in identity governance; established restricted storage and access for recordings.
• Testing/QA: Ran in shadow mode by creating grants with short expirations on non?production databases; validated approvals, MFA, and recording behavior; exercised break?glass and exception paths; tuned role templates and redaction rules; rehearsed periodic review notifications and removals.
• Rollout: Onboarded shared development databases first, then production and sensitive datasets; migrated standing groups into time?bound packages; kept manual grant paths as a controlled fallback early on; tightened maker?checker rules after stability; expanded session recording coverage as teams grew comfortable.
• Training/hand?off: Delivered sessions for DBAs, service owners, and support on request submission, approval handling, and session usage; published runbooks for break?glass, renewals, and incident response; updated SOPs for onboarding, offboarding, and contractor access; transferred policy ownership and dashboards to Identity and Security with DBA participation under change control.
• Human?in?the?loop review: Established recurring reviews for exception aging, high?risk recordings, and access denials; recorded decisions with rationale and effective dates; improvements flowed back into role mappings, approval rules, and recording scopes.

Results

Database access moved from standing privileges to governed, time?bound grants. Approvals lived in the same system that enforced sessions, and grants expired without manual cleanup. Emergency access paths were documented and recorded, which reduced the shadow footprint left behind after incidents. MFA at the start of each session and posture checks added a dependable gate that did not require re?platforming identity or databases.

Evidence became consistent. Session recordings and metadata linked to tickets and approval records, and periodic reviews removed access that no longer had a business sponsor. Compliance teams requested packets that showed who approved a grant, which session ran, and when access ended—without detours into inboxes and ad hoc notes. The lab kept its databases, identity, and ITSM; the addition was a PAM?backed workflow and review cycle that made access predictable and auditable.

What Changed for the Team

• Before: Long?lived group membership and shared passwords. After: Time?bound grants and brokered sessions with automatic expiry.
• Before: Approvals lived in email. After: Requests, approvals, and grants tied together in ITSM and PAM.
• Before: Session logs varied by platform. After: PAM recorded sessions with consistent metadata and restricted playback.
• Before: Emergency access lingered. After: Break?glass paths expired and were reviewed with recordings.
• Before: Audits stitched evidence from many places. After: Exportable packets contained approvals, sessions, and outcomes.
• Before: Access rarely revisited. After: Periodic reviews removed unused or unjustified privileges.

Key Takeaways

• Make database access ephemeral; grant just?in?time roles that expire automatically.
• Tie approvals to enforcement; connect ITSM requests to PAM sessions with MFA and recording.
• Record what matters; session metadata and playback turn investigations and audits into routine work.
• Keep a safety path; document break?glass access with short windows and post?event review.
• Review on a cadence; owner?driven access reviews prevent privilege creep.
• Integrate, don’t replace; keep identity, databases, and ITSM—add a PAM and governance layer across them.

FAQ

What tools did this integrate with? Requests and approvals ran through the existing ITSM platform (for example, ServiceNow). Privileged access and session recording used a PAM solution such as CyberArk Privileged Access Manager. MFA and single sign?on relied on the current identity provider. Periodic reviews used identity governance capabilities like Microsoft Entra Access Reviews. Sessions connected to PostgreSQL, SQL Server, and MySQL using PAM connectors, and logs flowed to the SIEM.

How did you handle quality control and governance? Approval matrices, role templates, and expiry policies lived under change control with owners and rationale. Grants required reason codes, environment tags, and data sensitivity. Sensitive roles followed maker?checker approvals. Session recordings and metadata were stored with restricted access, and periodic reviews removed access that lacked renewed sponsorship. All actions were logged with timestamps, request links, and policy versions.

How did you roll this out without disruption? The team piloted on non?production databases and short?lived service tasks. Existing access paths remained as a fallback while PAM sessions and expirations proved stable. Once owners were comfortable with recording and approvals, production and sensitive datasets were onboarded. Standing groups were migrated into time?bound packages in waves, with communication and training before each change.

How were MFA and device posture enforced? MFA prompts occurred at session start through the existing identity provider. Where supported, device posture and network checks were evaluated before brokering a session. Exceptions for lab equipment or partner devices followed documented paths with compensating controls and shorter access windows.

How did you manage emergency access and break?glass? A documented break?glass catalog allowed short?window access with owner notification and automatic expiry. All break?glass sessions were recorded and reviewed after the event. Follow?up tasks ensured any temporary roles or credentials were removed or rotated.

How did this address privacy and sensitive data handling? Session recordings were restricted to a small set of reviewers under need?to?know permissions. Redaction patterns masked sensitive values in logs, and retention policies aligned recordings to regulatory requirements. Playback access was audited, and requests for access to recordings required approval.

What about service accounts and automated jobs? Service accounts were vaulted in PAM with scoped permissions and rotation schedules. Where automation required credentials, checkouts were limited to specific tasks with audit trails. Long?lived secrets were reduced, and ownership and renewal tasks were assigned in the same workflow.

How were visiting collaborators and contractors handled? Requests captured sponsor, project, and end date. Grants were time?bound with optional re?approval. External identities used the existing federation model, and sessions still required MFA and recording. Expirations and reviews ensured access did not linger beyond the engagement.