Nederlands
This carries risk. If your acceptance or test environment runs on the same server as production, pentest activities can affect the production environment. This does not automatically mean a pentest is impossible, but it does mean we take extra precautions and you must inform us in advance.
What are the risks
- Slow response times on production. During a pentest many requests are sent to the test environment. On a shared server these requests share CPU, memory and network bandwidth with production requests.
- Resource exhaustion. Automated scans can briefly cause a spike that overloads the database, application server or caching layer. Visible to production users as slowness or timeouts.
- Log pollution. Test traffic appears in the same logs as production traffic. This complicates incident analysis and can trigger false positives in security monitoring.
- Unintended cross-contamination. Through misconfiguration, files, sessions or database connections can accidentally leak between environments.
- Rate-limiting confusion. If DongIT's IP addresses are whitelisted for the test environment, this whitelisting may also apply to production. This compromises the protection of the production environment during the test period.
How DongIT handles this
When you inform us in advance of this situation, we adjust our approach:
- Rate-limiting on our side. We reduce the number of concurrent requests so production is less loaded.
- Test window outside peak hours. Intensive test activities are scheduled during quiet moments (for example evenings or weekends).
- Active monitoring during the test. Our pentesters monitor production metrics and adjust pace if impact becomes noticeable.
- Restriction of aggressive techniques. Denial-of-service testing, brute-force on login endpoints and resource-intensive fuzzing are avoided or only used in controlled form.
- Emergency stop procedure. Your contact person can indicate at any time that we should pause, upon which we immediately suspend all test activities.
Recommendations for separation
For future pentests and general protection of your production environment we recommend separating test and production environments. This can be done at various levels:
- Separate VMs or containers. Minimal separation: separate processes on the same physical hardware. Prevents application-level interference.
- Separate physical servers. Better separation: no shared CPU, memory or storage. Prevents resource contention.
- Separate network segments. Network traffic separated as well, with firewall rules between environments.
- Separate cloud subscriptions. In Azure, AWS or GCP: separate accounts, tenants or projects. Ideal for larger organizations.
When is a shared server acceptable
For smaller organizations with limited resources, a shared server can be temporarily workable under these conditions:
- Communicated in advance of the pentest
- Test window outside production peak hours
- Full production backup available
- Limited scope: no destructive tests
- Active contact person during the entire test period
Learn more about pentest environments? See the FAQ on why pentesting on an acceptance or test environment. Contact us for a complimentary scoping conversation.