Update file structure and add documentation for data destruction veri…

…fication in the cloud

FileStructure.md

@@ -0,0 +1,77 @@
+
+# File Structure 
+
+## Overview
+This file aims to give a clear understanding of the role and functionality of each component within the project.
+
+## Backend Files
+
+### Go Files in the Backend
+
+- **main.go**
+  - The entry point of the Go application. It sets up the web server and ties together all the components of the backend.
+
+- **/config/config.go**
+  - Contains configuration-related code, such as reading environment variables and setting up global configuration parameters.
+
+- **/db/database.go**
+  - Manages database connections and provides an interface for database operations.
+
+- **/db/migration/migration.go**
+  - Handles database migrations, ensuring the database schema is up-to-date.
+
+- **/db/seed/seed.go**
+  - Used for seeding the database with initial data for development or testing.
+
+- **/utils/**
+  - This directory contains utility functions and helpers that are used across the application.
+  - Includes files like `errs.go` for error handling, `response.go` for standardized API responses, etc.
+
+### API Handlers
+
+- **/api/handlers/**
+  - Contains handler functions for API endpoints.
+  - Files like `cloud_providers_controller.go`, `verification_controller.go`, and `certificate_controller.go` define the logic for respective API endpoints.
+
+### Services
+
+- **/api/services/**
+  - Implements business logic and interacts with external services and databases.
+  - Includes service implementations like `AWSVerificationService`, and interfaces like `VerificationService`.
+
+## Frontend Files
+
+- **/public/**
+  - Contains HTML templates and HTMX files for the frontend.
+  - `index.templ` is the main entry point for the frontend interface.
+
+- **/dist/**
+  - Contains compiled and minified CSS and JavaScript files, along with other static assets like images and icons.
+
+## Security Files
+
+- **/utils/security/**
+  - Contains security-related modules like `auth.go`, `credentials.go`, and `encryption.go`, which handle various aspects of application security.
+
+## Docker and Deployment
+
+- **Dockerfile**
+  - Contains instructions for building the Docker image of the Go application.
+
+- **docker-compose.yaml**
+  - Defines the multi-container Docker setup, including the Go application and the Nginx server for the frontend.
+
+## Documentation and Configuration
+
+- **README.md**
+  - Provides an overview of the project, setup instructions, and general information.
+
+- **.env.sample**
+  - A sample environment file with necessary environment variables for running the application.
+
+- **Makefile**
+  - Contains scripts to automate common development tasks like building, running, and testing the application.
+
+---
+
+This file should be updated as new components are added or existing ones are modified.

README.md

@@ -31,6 +31,91 @@ DataDemise is an application for certifying and verifying the destruction of dat
    - Implemented `VerificationService` interface and specific services like `AWSVerificationService` to check the complete destruction of data.
 
 
+### File Structure
+
+```
+├── Dockerfile
+├── Makefile
+├── README.md
+├── _README.md
+├── api
+│   ├── handlers
+│   │   ├── certificate_controller.go
+│   │   ├── cloud_providers_controller.go
+│   │   └── verification_controller.go
+│   └── services
+│       ├── aws.go
+│       ├── aws_verification_service.go
+│       ├── azure.go
+│       ├── azure_verification_service.go
+│       ├── gcp.go
+│       ├── gcp_verification_service.go
+│       ├── service_factory.go
+│       └── verification_service.go
+├── certificates
+│   └── generator.go
+├── config
+│   └── config.go
+├── db
+│   ├── database.go
+│   ├── migration
+│   │   └── migration.go
+│   └── seed
+│       └── seed.go
+├── dist
+│   ├── favicon.ico
+│   ├── htmx.min.js
+│   ├── main.css
+│   └── tailwind.css
+├── docker-compose.yaml
+├── docs
+│   ├── Building the Application.md
+│   └── Frontend with HTMX.md
+├── env.sample
+├── go.mod
+├── go.sum
+├── main.go
+├── public
+│   ├── base.templ
+│   ├── base_templ.go
+│   ├── index.templ
+│   └── index_templ.go
+├── tailwind.config.js
+├── template
+│   └── template.go
+└── utils
+    ├── constants
+    │   └── common.go
+    ├── errs
+    │   └── errs.go
+    ├── markd
+    │   └── markdown.go
+    ├── resp
+    │   ├── errors.go
+    │   └── response.go
+    ├── routing
+    │   └── setup.go
+    ├── scopes
+    │   └── pagination.go
+    ├── security
+    │   ├── access_control.go
+    │   ├── api_security.go
+    │   ├── audit_log.go
+    │   ├── auth.go
+    │   ├── config.go
+    │   ├── credentials.go
+    │   ├── encryption.go
+    │   ├── sanitizer.go
+    │   ├── security_errors.go
+    │   ├── security_test.go
+    │   ├── tls_config.go
+    │   └── utils.go
+    ├── tern
+    │   └── ternary.go
+    └── typeext
+        └── jsonb.go
+```
+
 
 
 

docs/Data Destruction Verification.md

@@ -0,0 +1,44 @@
+In the context of data destruction in the cloud, many of the elements you've listed in a regular data destruction certificate can have counterparts. Here's how they might translate to the cloud environment:
+
+## Manufacturer, Model, Serial Number (if applicable):
+In the cloud, you won't have physical hardware, so there won't be a manufacturer, model, or serial number. Instead, you would identify the specific virtual or cloud-based resources being dealt with.
+
+## Organizationally Assigned Media or Property Number (if applicable):
+In a cloud environment, this could translate to resource IDs or unique identifiers assigned by the cloud service provider.
+
+## Media Type (i.e., magnetic, flash memory, hybrid, etc.):
+In the cloud, you might categorize resources based on their storage type, such as object storage, block storage, or database storage.
+
+## Media Source (i.e., user or computer the media came from):
+In the cloud, this would involve tracking the origin of the data, such as which user or application created or uploaded it.
+
+## Pre-Sanitization Confidentiality Categorization (optional):
+In the cloud, this would involve classifying the sensitivity of the data before deletion or sanitization.
+
+## Sanitization Description (i.e., Clear, Purge, Destroy):
+In a cloud environment, this could refer to the method used to delete or sanitize data, such as data encryption key rotation, data obfuscation, or secure deletion.
+
+## Method Used (i.e., degauss, overwrite, block erase, crypto erase, etc.):
+In the cloud, this would relate to the specific method or process applied to ensure data deletion or security measures taken.
+
+## Tool Used (including version):
+In the cloud, this would involve specifying the tools or services used for data deletion or sanitization, along with their versions.
+
+## Verification Method (i.e., full, quick sampling, etc.):
+In a cloud context, this would describe how the effectiveness of data sanitization or deletion was verified, such as through audits, automated scripts, or manual checks.
+
+## ## Post-Sanitization Confidentiality Categorization (optional):
+Similar to pre-sanitization categorization, this would involve classifying the data's sensitivity after sanitization.
+
+Post-Sanitization Destination (if known):
+In the cloud, this would specify where the data is moved or deleted to after sanitization, such as archived storage or complete removal.
+
+## For Both Sanitization and Verification:
+
+Name of Person: The individual or entity responsible for overseeing the process in the cloud environment.
+Position/Title of Person: The role or responsibility of the person overseeing the process.
+Date: The date when the sanitization and verification processes were performed.
+Location: The location or environment where the cloud resources are hosted.
+Phone or Other Contact Information: Contact information of the responsible party.
+Signature: This can be a digital signature or other means of authentication.
+