Security Architecture & Data Governance
LogBook protects university course records with cryptographic envelope encryption, kernel-enforced PostgreSQL tenant isolation, verified read-only LMS integrations, and local-first cryptographic storage.
Core Architectural Safeguards
Azure Key Vault Envelope Encryption
Two-tier cryptographic hierarchy. Sensitive student evaluations and academic records are encrypted using per-tenant Data Encryption Keys (DEKs) running AES-256-GCM. DEKs are wrapped and unwrap-protected by Key Encryption Keys (KEKs) housed inside FIPS 140-2 Level 2 validated hardware security modules (HSMs) in Azure Key Vault.
PostgreSQL Row-Level Security on Neon
Multi-tenant data isolation enforced directly at the Neon PostgreSQL database engine level via Row-Level Security (RLS) policies. Every backend Go transaction binds to verified Clerk JWT claims, locking database sessions to the instructor ID. Cross-tenant reads or writes are rejected by PostgreSQL itself.
Read-Only Google Classroom OAuth
LogBook requests strictly read-only OAuth scopes to pull course rosters, assignments, and submissions. LogBook cannot create, edit, or delete items in your Classroom or Drive. Disconnecting the integration issues an instant remote token revocation call to Google and purges all credentials.
Local Storage Cryptography for Offline Mode
Native Web Cryptography API (SubtleCrypto AES-GCM-256) protects offline course rosters, attendance logs, and grading inputs before writing to browser IndexedDB. Stored records remain encrypted on your device when offline and synchronize over TLS 1.3 upon reconnecting.
How does Azure Key Vault envelope encryption protect academic data?
LogBook implements two-tier envelope encryption where per-tenant Data Encryption Keys (DEKs) encrypt sensitive academic records with AES-256-GCM and are wrapped by Key Encryption Keys (KEKs) managed within Azure Key Vault. Plaintext DEKs remain exclusively in volatile application memory during active request cycles and are never committed to non-volatile storage.
When an instructor opens a course gradebook, the Go API receives the encrypted DEK from PostgreSQL and requests an unwrap operation from Azure Key Vault using managed identities. The decrypted DEK decrypts course records in memory. Once the response completes, memory buffers holding plaintext keys are purged. This architecture isolates tenant data at rest and eliminates the requirement for faculty members to remember or input an auxiliary master password.
- Hardware Security Modules: FIPS 140-2 Level 2 validated HSMs
- Zero Database Master Passwords: Keys managed via Azure IAM
- Per-Tenant Isolation: Each instructor workspace maintains distinct DEKs
- Key Rotation: Master KEK rotation without bulk re-encrypting records
How does PostgreSQL row-level security enforce tenant isolation?
Multi-tenant data separation is enforced directly within the Neon PostgreSQL kernel using Row-Level Security (RLS) policies keyed to verified Clerk JWT session tokens. Every database transaction executes within a strictly scoped tenant session context, preventing cross-faculty data access even if application queries are malformed.
When an HTTP request reaches the Go backend, the server verifies the Clerk cryptographic signature, validates session expiry, and injects the instructor's unique ID into the active database connection session (SET LOCAL app.current_user_id = $1). Neon PostgreSQL evaluates every SELECT, UPDATE, and DELETE against the RLS predicate. Even a raw database operator query lacking tenant scope filters cannot accidentally return rows belonging to another professor.
What Google Classroom permissions does LogBook access and how are tokens revoked?
LogBook operates under four read-only OAuth scopes and cannot modify, create, or delete classroom data. Disconnecting Google Classroom triggers an immediate API revocation request to Google's OAuth 2.0 endpoints and permanently purges stored credentials from the database.
| OAuth Scope | Access Level | Operational Purpose |
|---|---|---|
| classroom.courses.readonly | Read-Only | Fetch active course titles and course IDs to select for sync |
| classroom.coursework.students.readonly | Read-Only | Import coursework assignments, max points, and student submission grades |
| classroom.rosters.readonly | Read-Only | Import enrolled student rosters and identifiers into course rosters |
| classroom.profile.emails | Read-Only | Map student email addresses for individualized grade report delivery |
Google integration compliance: LogBook never asks for Drive write privileges, Classroom management access, or administrative domain scopes. When you click "Disconnect" in Course Settings, LogBook calls https://oauth2.googleapis.com/revoke?token=... and wipes all stored tokens.
How does local storage cryptography secure offline grading?
For offline grading during classroom Wi-Fi outages, LogBook secures local rosters and evaluation records using the browser's native Web Cryptography API (SubtleCrypto AES-GCM-256) before writing to IndexedDB. Cached records remain encrypted at rest on the instructor's device and synchronize over TLS 1.3 when network connectivity is re-established.
When an instructor opens LogBook without internet connectivity, local cryptographic keys held in authenticated memory decrypt the client-side Dexie/IndexedDB database. Instructors can record grades, take attendance, or modify syllabus schemes. Each local change receives a monotonically increasing vector timestamp. Once connectivity resumes, the synchronization engine reconciles local modifications against the server, ensuring no records are lost or overwritten.
Institutional IT Audit Specification Matrix
This technical reference outlines system architecture specifications for institutional IT security reviews, HECVAT questionnaires, and FERPA/GDPR compliance audits.
| Security Domain | Implementation Technology | Cryptographic & Architectural Guarantee |
|---|---|---|
| Key Management | Azure Key Vault Managed HSM | Two-tier KEK/DEK envelope encryption; KEKs never leave hardware security perimeter. |
| Relational Persistence | Neon PostgreSQL with RLS | Kernel-level multi-tenant isolation; parameterized session variables; continuous WAL backups. |
| Authentication & Session | Clerk Session JWT (RSA-256) | 1-hour rotating JWT tokens; CSRF protection; enterprise SAML / Google Workspace SSO. |
| Data in Transit | TLS 1.3 / HSTS Preload | Forced TLS 1.3 encryption with preloaded HSTS headers (max-age=63072000; preload). |
| Third-Party LMS Sync | Google Classroom OAuth 2.0 | Verified read-only scopes; zero write privileges; instant remote token revocation endpoint. |
| Client-Side Cache | Web Cryptography API (AES-GCM) | Encrypted IndexedDB offline cache; client keys purged from memory upon sign out. |
| Student Data Stewardship | Zero Third-Party Trackers | No advertising networks, no student data brokering, no external telemetry on grades. |
Frequently Asked Questions by IT Administrators & Faculty
Is student grade and attendance data encrypted in transit and at rest?
Yes. All network traffic between web clients, mobile apps, and the backend Go API uses TLS 1.3 with HSTS preloaded. At rest, sensitive fields are protected by Azure Key Vault envelope encryption using AES-256-GCM DEKs, and database volumes on Neon PostgreSQL use full-disk encryption.
Does LogBook comply with FERPA requirements for student privacy?
Yes. Under FERPA (Family Educational Rights and Privacy Act), educational records must remain protected from unauthorized disclosure. LogBook acts as a secure operational processor: student records belong exclusively to the instructor and their institution. LogBook never sells student data, displays advertisements, or shares records with third-party brokers.
Can university administrators or other instructors see my course grades?
No. LogBook enforces strict tenant isolation at the PostgreSQL kernel level via Row-Level Security policies. Only the authenticated instructor who created the course workspace can access student grades, evaluation records, and private notes.
Can LogBook alter assignments, grades, or files in my Google Classroom?
No. LogBook operates under strictly read-only OAuth scopes verified by Google Trust & Safety. The application possesses zero permissions to create, update, or delete courses, assignments, student submissions, or Google Drive documents.
What happens to local offline records if I sign out or clear my browser data?
Signing out explicitly clears the ephemeral client decryption keys held in memory. Local offline records are stored in browser IndexedDB. Before signing out or clearing browser cookies, ensure any pending offline edits have completed synchronization over an active internet connection.
How does LogBook handle vulnerability disclosure and security incident response?
LogBook maintains a coordinated vulnerability disclosure policy. Security researchers and institutional IT auditors can report findings to info@syedsystems.dev. Our engineering team confirms reports within 48 business hours and deploys critical mitigations through automated CI/CD pipelines.
Institutional Security & Audit Inquiries
Need to complete a HECVAT questionnaire, request a Data Processing Agreement (DPA), or submit a vulnerability report? Our security engineering team provides direct responses to university IT departments.