Day62: Security Architecture & Incremental Migration – From Identity & Access to Legacy System Modernization

Overview

Date: 2026‑08‑20  Stage: Phase 4 – Second pass of case analysis  Study time: 45 minutes  Goal: Identify identity, permission, data and audit risks; design authentication, authorization, zero‑trust, data‑protection and security‑response solutions; evaluate legacy system technical level and business value; choose an incremental migration strategy and specify data‑sync, verification and rollback measures.

Two Main Tracks

Security:   Protect objects → Threats & vulnerabilities → Authentication → Authorization → Data protection → Audit detection → Response & recovery → Verification

Evolution:  Change & goals → Legacy system assessment → Target architecture definition → Gap identification → Phased migration → Data sync & validation → Gray‑scale / rollback → Decommission

Strict Requirements

Authentication and authorization must be separate; merging them fails.

Only RBAC without object‑level checks (e.g., "doctor can view any patient") is incomplete.

Only database encryption without transport, usage, backup and key‑management is incomplete.

Logging only login events cannot answer "who viewed which record" – not a valid security audit.

Writing "tear down the old system" without analysis is not accepted.

Stating "phased migration" without specifying segmentation, data sync and rollback is incomplete.

Writing data in both systems without defining an authoritative source and reconciliation mechanism fails.

Testing only "run the UI" without functional, data, security and rollback acceptance items is incomplete.

Reference Materials (previous days)

Day38 – Security Architecture

Day53 – Information Security Basics

Day54 – Access Control & Security Protocols

Day34 – Architecture Evolution & Maintenance

Day29 – Enterprise Architecture

Day57 – Case‑Study Reading & Answer Framework

Case: Regional Medical Platform Security Renovation & Migration

The platform has operated for 12 years, connects 80 hospitals and stores ~20 million patient identities, registrations, records, prescriptions and settlement data. It uses an early monolithic architecture with a single application and shared database. Although technically outdated, the platform must remain continuously available for registration, record lookup and settlement.

The health authority plans an 18‑month new platform with the following requirements:

First migrate registration and report query, then medical records, prescriptions and settlement.

Core services must stay online during migration.

Historical medical data must not be lost; key operations must be traceable.

Patients may only access their own data.

Doctors may only access records of patients they are treating.

Partner institutions may only use contracted APIs and data scopes.

High‑risk accesses must trigger an alarm within 30 seconds.

Each migration batch must be rollback‑able.

Material 1 – Unrestricted Access After Login

Patients, doctors and admins log in with username/password.

Multiple operators share a super‑admin account.

Menu permissions are granted by role (doctor, nurse, admin).

After login, a doctor can change the patient_id in the URL to view other patients' records.

Partner institutions share a long‑lived static API key.

Internal services trust source IP and skip identity/permission checks.

Service‑to‑service communication is plain HTTP.

Incident: an attacker stole a doctor's password, enumerated patient IDs and downloaded 30 000 records. The breach was detected only after two hours; logs were insufficient to pinpoint which fields were accessed or whether logs had been tampered.

Material 2 – Encryption Is Not Enough

Medical‑record export files are stored in plaintext on a shared directory.

Test environment copies real production data without sanitisation.

Database backups and production data are accessed with the same cloud account.

Encryption keys are hard‑coded in application config and have never been rotated.

Electronic prescriptions are plain images without digital signatures.

Logs are scattered on each server; administrators can delete them.

Logs only record "interface call succeeded" without subject, patient, operation or result.

Material 3 – Legacy System Constraints

Technology stack is out of maintenance; security patches are hard to apply.

Code is heavily coupled; registration, records, prescriptions and settlement share many tables.

Documentation and automated tests are lacking; some settlement rules exist only in code.

The system supports core business for 80 hospitals – high business value.

A full rewrite is estimated to take two years, during which requirements will continue to evolve.

A direct switch could cause registration outages, settlement errors and loss of historical records.

Material 4 – Pilot Migration Issues

First migrated the report‑query module:

1. Full copy of historical reports to the new database.
2. CDC reads the old DB change log and syncs new/updated rows to the new DB.
3. API gateway routes 5 % of query traffic to the new service.
4. If results are abnormal, traffic can be switched back to the old service.

Problems discovered during the pilot:

Both old and new systems can modify report status, but no authoritative source is defined.

Network retries cause some change events to be processed repeatedly.

The shared super‑admin account of the old system is also used to call the new platform.

Migration data files remain in a temporary directory for a long time.

Only total record counts were compared; key fields and business results were not verified row‑by‑row.

Material 5 – Incomplete Acceptance Criteria

No privilege‑escalation or replay testing.

No key rotation, token revocation or audit‑log integrity checks.

No full‑/incremental migration reconciliation.

No peak‑load performance testing.

No gray‑scale expansion and rollback drills.

No backup‑restore and security‑incident response exercises.

Question 1 – Risk Identification & Security Goals (7 pts)

Separate threat, vulnerability and risk:

Threat: attacker steals a doctor’s account and reads many unrelated records.

Vulnerability: single password, missing object‑level permission, patient_id enumeration, insufficient detection/audit.

Risk: large‑scale patient‑privacy breach with no timely containment or accountability.

Using CIA and auditability, the answer must list confidentiality, integrity or auditability issues with concrete evidence from the material.

Six‑element security quality‑attribute scenario (source, stimulus, environment, artifact, response, response metric) is required. Example response metric: all unauthorized accesses are denied, an alarm is raised within 30 seconds, and audit logs contain subject, patient, interface, timestamp, source and result.

Question 2 – Authentication, Authorization & Zero Trust (7 pts)

Define AAA:

Authentication – prove who you are.

Authorization – decide what you may do.

Accounting/Auditing – record what you actually did.

Login success does not guarantee correct authorization; a doctor can still view unrelated records.

Why RBAC alone is insufficient:

Role = doctor, nurse, pharmacist, etc.

Attributes needed: current treatment relationship, belonging institution, time, device, risk level.

Solution: grant basic permissions with RBAC, then apply ABAC or object‑level checks for patient‑doctor relationship, institution, time and device.

Matrix of subjects, authentication measures and authorization measures (patients, doctors, ops staff, partner institutions, internal services) is provided in the source.

MFA must involve at least two different factor categories (e.g., password + OTP or hardware token). Two passwords belong to the same "knowledge" factor and do not satisfy MFA.

Zero‑trust principle: never trust internal IP; every request is authenticated, authorized and encrypted. Service‑to‑service calls use service identities, short‑lived credentials and mTLS.

Question 3 – Data Protection, Auditing & Response (7 pts)

Data‑life‑cycle protection:

Classification & grading of identity, records, prescriptions, payment and audit data.

Transport encryption: TLS for external traffic, mTLS for internal services; no clear‑text communication.

Storage encryption: databases, object storage, export files and backups; sensitive fields protected separately.

Usage controls: minimal authorisation for queries/exports, test data sanitisation, approval and alerts for bulk operations.

Sharing limits: per‑institution, purpose, field and time‑window restrictions.

Archiving & destruction: timely archiving or secure deletion; temporary migration files must be encrypted and removed promptly.

Key‑management steps (generation, secure storage, authorised use, periodic rotation, revocation, audit) are listed.

Electronic prescription protection: compute hash, apply digital signature with hospital/doctor private key, verify with certificate‑bound public key – ensures integrity, source authenticity and non‑repudiation.

Audit log must record: who (user/partner/service), when (request & processing time), where (device/IP/session), what (patient/record/prescription/interface), action (query, modify, export, delete), result (allow/deny/failure and reason), and correlation IDs.

Batch‑over‑privilege detection & response workflow:

Detect: high‑frequency patient_id access, continuous over‑privilege, abnormal location/device.
Respond: reject request, rate‑limit, freeze account, revoke token, isolate source.
Preserve evidence: retain audit logs, call chain, accessed objects, time window.
Recover: fix permission rules, confirm affected data and subjects, follow incident‑response process.
Improve: root‑cause analysis, update policies, tests and alert thresholds.

Question 4 – Legacy System Evaluation & Migration Strategy (8 pts)

Assessment from Material 3:

Low technical level (out‑of‑maintenance stack, heavy coupling, missing docs/tests).

High business value (supports 80 hospitals, stores critical rules and data).

Result: place in the "low‑tech, high‑value" quadrant → adopt an inheritance strategy (retain valuable rules, data and functions, then gradually replace).

Four actions (do not mix): reverse engineering, refactoring, re‑engineering, migration.

Why a full rewrite and direct switch is unsafe:

Hidden business rules may be omitted.

Requirements will evolve during the two‑year rewrite.

Lack of tests makes behaviour equivalence unproven.

Massive data migration concentrates risk.

Switch failure would affect all 80 hospitals simultaneously.

No opportunity for small‑scale feedback or gradual error correction.

Rollback windows and data recovery would be extremely difficult.

Migration strategy:

Segmented conversion as the primary approach (by module, hospital, user or process).

Parallel verification for high‑risk batches (e.g., settlement, prescription) with limited time windows.

Never let new and old systems permanently perform all writes; use a single authoritative writer per capability.

Question 5 – Incremental Migration, Data Consistency & Verification (6 pts)

From Material 4, define the authoritative data source for each phase and the single main writer. The other side becomes a read‑only replica or sync target.

Migration steps:

1. Full historical data copy.
2. CDC captures old‑DB change log and streams inserts/updates/deletes to the new platform.
3. Assign a unique event_id to each change; consumer checks if the ID was already processed → idempotent handling.
4. Four‑layer data reconciliation:
   • Count validation.
   • Field validation (key fields, nulls, encoding).
   • Relationship validation (patient‑record‑prescription‑settlement links).
   • Business‑logic validation (amounts, statuses, rule outcomes).

Security boundaries during coexistence:

Old‑system accounts cannot impersonate new‑service identities.

Both old and new APIs require authentication, authorisation, encryption and audit.

Adapter layer exposes only the minimal interfaces and fields needed for migration.

Migration accounts have least‑privilege, batch‑scoped lifetimes and are revoked after use.

Temporary migration files are encrypted, time‑limited and cleaned up.

Test‑environment data is always sanitised.

Logs from both systems flow into a unified, tamper‑proof audit store.

Gray‑scale rollout and rollback triggers:

1. Internal users or a small set of hospitals use the new service.
2. Gradually increase traffic (5 %, 20 %, 50 %, 100 %).
3. After each step monitor error rate, response time, over‑privilege alerts and data‑diff.
4. If any metric exceeds the threshold, stop expansion, switch traffic back to the old system and reconcile new data generated during the gray‑scale.
5. Fix the issue, re‑validate and resume.

Acceptance criteria (five categories):

Functional – new and old critical workflows produce identical results.

Data – full‑ and incremental reconciliation of record count, fields, relationships and business outcomes.

Performance – meet target concurrency, throughput (P95/P99), error rate and resource utilisation.

Security – authentication, object‑level authorisation, replay protection, key rotation, audit‑log integrity and 30‑second alert requirement.

Operations – gray‑scale, rollback, backup‑restore and security‑incident response drills.

Key Takeaways

Security must be embedded in every migration batch, not added after the fact.

Combine identity, MFA, RBAC + ABAC, zero‑trust service authentication and encrypted communication.

Protect data throughout its lifecycle; manage keys separately and rotate them.

Maintain complete, tamper‑proof audit logs to enable rapid detection and accountability.

Assess legacy systems on technical debt vs business value; adopt inheritance and incremental migration rather than a big‑bang rewrite.

Define authoritative data sources, use CDC with unique IDs, ensure idempotency and perform multi‑layer data verification.

Use gray‑scale expansion with clear rollback conditions and comprehensive acceptance testing before retiring old components.