Security Auditing & Monitoring
Relevant source files
The following files were used as context for generating this wiki page:
- src/components/admin/ComprehensiveSecurityDashboard.tsx
- src/components/SecurityModule.tsx
- src/components/SecurityAuditDashboard.tsx
- src/components/admin/SecurityTestingDashboard.tsx
- supabase/migrations/20251024040415_846fb831-b3fa-4c38-a4a8-e35c5302f3de.sql
- supabase/migrations/20250926024720_c07195cf-baa9-491c-8713-f1476c3e5de9.sql
- supabase/migrations/20250825222411_cc14f1cc-fc2b-418d-907f-89337412d443.sql
- scripts/verify_deployment.sql
The Security Auditing & Monitoring system is a core infrastructure component designed to ensure the integrity, availability, and confidentiality of the Monarch Property Management platform. It provides real-time visibility into system health, user actions, and potential security threats through a combination of database-level triggers, Row-Level Security (RLS) policies, and administrative dashboards.
The system encompasses three primary pillars: proactive monitoring (system health and rate limiting), reactive auditing (immutable action logs), and vulnerability assessment (automated security scans and testing suites). These components work together to provide a "Security Command Center" for administrators to manage the platform's security posture.
Sources: src/components/admin/ComprehensiveSecurityDashboard.tsx:206-214, src/components/SecurityModule.tsx:162-170, README.md
System Architecture & Data Flow
The monitoring architecture relies on Supabase for data persistence and real-time updates. Security events are captured at the database level via triggers and stored in specialized tables. The frontend consumes this data using the Supabase client, providing real-time visualizations for administrators.
Security Event Lifecycle
The following diagram illustrates how a security event is captured, processed, and displayed within the system.
The system uses postgres_changes channels to provide live updates to the monitoring dashboards without requiring manual refreshes.
Sources: src/components/SecurityModule.tsx:156-184, supabase/migrations/20250825222411_cc14f1cc-fc2b-418d-907f-89337412d443.sql:128-150
Core Monitoring Components
Audit Logging
The audit logging system creates an immutable trail of significant user and system actions. It captures the actor, the action performed (INSERT, UPDATE, DELETE), the target table, and specific record identifiers.
| Field | Type | Description |
|---|---|---|
user_id | UUID | The identifier of the user who performed the action. |
action | TEXT | The operation type (e.g., 'UPDATE_ATTEMPT', 'SECURITY_HARDENING'). |
table_name | TEXT | The target database table. |
record_id | TEXT | The ID of the affected record. |
new_values | JSONB | A snapshot of the data after the change. |
ip_address | INET | The network address of the requester. |
Sources: src/components/SecurityModule.tsx:14-25, supabase/migrations/20251024040415_846fb831-b3fa-4c38-a4a8-e35c5302f3de.sql:92-110
Security Event Tracking
Beyond standard audits, the system tracks specific security-related occurrences such as failed authentication attempts (AUTH_FAILED), blocked access attempts, and suspicious patterns. These are assigned severity levels (Low, Medium, High, Critical) to facilitate prioritization.
Sources: src/components/admin/ComprehensiveSecurityDashboard.tsx:85-110, supabase/migrations/20250926024720_c07195cf-baa9-491c-8713-f1476c3e5de9.sql:121-135
System Health & Rate Limiting
Monitoring includes active health checks for the database, authentication service, storage buckets, and edge functions. Rate limiting is enforced both on the client and server side to prevent brute-force attacks and API abuse, with a current window tracking requests per identifier.
Sources: src/components/SecurityModule.tsx:93-125, src/components/admin/SecurityTestingDashboard.tsx:88-95
Security Vulnerability Testing
The platform includes an automated testing suite that administrators can run to verify the efficacy of security controls.
Automated Test Suite Logic
The SecurityTestingDashboard executes a series of checks across four categories:
- Authentication: Validates password strength rejection and rate limiting.
- Authorization: Tests RLS enforcement by attempting unauthorized reads.
- Input Validation: Verifies XSS and SQL injection protection.
- Data Protection: Checks PII minimization and connection encryption.
Database Security Hardening
The monitoring system is underpinned by rigorous database-level security configurations implemented via SQL migrations.
Row-Level Security (RLS) Policies
RLS is the primary mechanism for data isolation. Policies are configured to restrict access based on the user's role and ID.
- Profiles: Restricted to
selforadminaccess only. - Audit Logs: Immutable; deletion is strictly prohibited via
FOR DELETE USING (false). - Financial Reports: Accessible only to Admins and Property Managers.
Security Helper Functions
Several SECURITY DEFINER functions are utilized to perform safe permission checks:
is_admin_user(user_uuid): Checks if a user has the 'admin' role inuser_roles.user_has_role(user_uuid, role_name): General-purpose role verification.validate_and_sanitize_input_enhanced(): Prevents SQL injection and XSS by checking for dangerous patterns likeUNION SELECTor<script>tags.
Sources: supabase/migrations/20251024040415_846fb831-b3fa-4c38-a4a8-e35c5302f3de.sql:75-87, supabase/migrations/20250926024720_c07195cf-baa9-491c-8713-f1476c3e5de9.sql:24-60, scripts/verify_deployment.sql:53-73
Summary
The Security Auditing & Monitoring system provides a multi-layered defense and observation strategy. By integrating real-time health monitoring with immutable audit trails and automated security testing, the platform ensures that administrators can detect, investigate, and mitigate security risks efficiently. The use of database-level enforcement through RLS and security-focused RPCs ensures that these monitoring capabilities are consistent across all access methods.
Sources: src/components/admin/ComprehensiveSecurityDashboard.tsx:1-15, README.md