# Network Security and Configurations

This article defines the security standards, network connectivity requirements, and access control guidelines for the askEdgi platform. The objective is to ensure secure deployment, operation, and integration of askEdgi across multiple deployment models while aligning with enterprise security, compliance, and audit expectations.

These guidelines provide transparency into how askEdgi protects sensitive metadata, controls platform access, encrypts communication, and enforces industry-standard security practices.

## Scope

These security guidelines apply to all AskEdgi platform components including:

* Java/Tomcat–based web application
* Python backend microservices
* Relational metadata databases (MySQL / PostgreSQL)
* Elasticsearch search and indexing engine
* Bridge server
* Bridge client
* Source system connectors and adapters

Supported deployment models include:

* OvalEdge SaaS hosted on AWS
* Customer-managed cloud deployments (AWS / Azure)
* On-premise deployments on VMs, Kubernetes, or OpenShift

## Assumptions

* askEdgi is deployed inside customer-controlled VPC or data-center networks
* Application access is allowed only via HTTPS
* Integration with enterprise Identity Providers (AD, Okta, Entra ID) is supported
* Databases and Elasticsearch are never publicly exposed
* Network segmentation and firewall controls follow customer security standards

## Identity, Access & Authentication

### Authentication

askEdgi supports enterprise Single Sign-On (SSO) using:

* SAML 2.0
* OpenID Connect (OIDC)

Supported identity providers include:

* Okta
* Microsoft Entra ID (Azure AD)
* Active Directory Federation Services (AD FS)
* Other standards-compliant IdPs

SaaS Requirements

* SSO mandatory for all named users
* MFA must be enforced at IdP level
* Shared accounts are not permitted

**Local Users**

Allowed only for:

* Initial platform bootstrap
* Emergency break-glass administration

Authentication Port:

* 443 / HTTPS

### Authorization

AskEdgi enforces Role-Based Access Control (RBAC).

Standard Roles

* Data Consumer
* Data Steward
* Administrator
* DevOps Administrator
* Lineage Operations

Authorization Principles

* Least privilege enforced
* No direct DB or Elasticsearch access for business users
* Admin access restricted to named individuals
* All access actions are auditable

### Credential & Secret Handling

Secrets are stored only in approved secret management systems:

* AWS Secrets Manager
* Azure Key Vault
* HashiCorp Vault

Security Controls

* No plaintext secrets in:
  * Property files
  * Source code
  * CI/CD pipelines
  * Kubernetes manifests
* Secrets injected dynamically at runtime
* Separate secrets per environment and tenant

Rotation Policy

* Every 90 days, or
* Immediately upon staff exit or security incident

## Application Security Guidelines

### Secure Configuration Baseline

* Default and demo users disabled
* Strong password policies enforced
* Session timeout and idle logout enabled
* Admin UI restricted by:
  * Corporate IP allowlists, or
  * Privileged admin groups

### Application Hardening

* HTTPS only (HTTP disabled)
* TLS 1.2 or higher
* Directory listing disabled
* Unnecessary headers removed
* Upload and request size limits enforced
* API rate limiting via WAF

### Internal Service Ports

| Component          | Port |
| ------------------ | ---- |
| Tomcat Application | 8080 |
| Python Services    | 8000 |
| Bridge Server      | 9443 |
| Elasticsearch      | 9200 |

All internal ports remain accessible only within private subnets.

### Dependency & Patch Management

* SBOM maintained for:
  * Java libraries
  * Python packages
  * OS dependencies
* Critical vulnerabilities patched within SLA
* Minor upgrades during scheduled maintenance
* Supported versions documented for:
  * Java
  * Tomcat
  * Database
  * Elasticsearch
  * OS

## Data Security

### Data at Rest

* Database and Elasticsearch encryption enabled
* Encrypted backups and snapshots
* Encryption via:
  * AWS KMS
  * Azure-managed keys
  * Customer-managed keys (optional)
* Separate keys per environment recommended

### Data in Transit

All communication uses TLS encryption.

| Source        | Destination   | Port | Purpose  |
| ------------- | ------------- | ---- | -------- |
| User Browser  | AskEdgi UI    | 443  | UI/API   |
| Application   | Database      | 3306 | Metadata |
| Application   | Elasticsearch | 9200 | Search   |
| Bridge Client | Bridge Server | 9443 | mTLS     |

{% hint style="info" %}
Mutual TLS (mTLS) ensures both server and client authentication.
{% endhint %}

### Data Masking & Logging

* PII masking supported in:
  * Search
  * Profiling
  * Lineage
* Logs never contain:
  * Passwords
  * Tokens
  * Secret
  * PII

## Network & Perimeter Security

* External access allowed only on 443
* Protected by:
  * ALB / NLB + WAF (cloud)
  * Reverse proxy/firewall (on-prem)
* No public access to:
  * Databases
  * Elasticsearch
  * Internal services
* Private connectivity preferred:
  * VPN
  * VPC peering
  * Private endpoints

## Logging, Monitoring & Incident Response

### Logging

* Centralized logging:
  * CloudWatch
  * Log Analytics
  * SIEM
* Audit logs include:
  * Authentication
  * Authorization
  * Configuration changes
  * Lineage updates

Monitoring

* CPU, memory, disk
* API latency and errors
* DB connections
* Elasticsearch index growth
* Bridge job execution

### Incident Response

* Severity levels: P1–P4
* Escalation: Support → DevOps → Engineering
* Includes isolation, RCA, and customer communication

## Secure SDLC & Deployment

* OWASP-aligned code reviews
* Automated secrets scanning
* Signed immutable Docker images
* Environment promotion: Dev → QA → UAT → Production
* Security testing:
  * SAST
  * DAST
  * Periodic penetration testing

## Shared Responsibility Matrix

### Customer Responsibilities

* Network perimeter
* Firewall and routing
* Identity provider and MFA
* Bridge client host security

### OvalEdge Responsibilities

* Application security
* Platform patching
* Vulnerability remediation

### Shared Responsibilities

* Database security
* Backup & disaster recovery
* Encryption key management
* Vulnerability monitoring

***

Copyright © 2026, OvalEdge LLC, Peachtree Corners, GA USA


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.ovaledge.com/release8.1/askedgi/security/network-security-and-configurations.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.