أمان يصمد أمام أخطائي: ست طبقات وإعداداتها كاملة

تحفظ FinyxWatt، منصتي لمحطات الكهرباء والمياه، عملاء محطات كثيرة وفواتيرهم وسنداتهم في قاعدة PostgreSQL واحدة. وكل استعلام يرسله الـ API لا يفصله عن كشف عملاء محطة لمحطة أخرى إلا شرط واحد منسي: WHERE tenant_id = ?. أنا من يكتب هذه الاستعلامات. وسيأتي يوم أنسى فيه الشرط.

لذلك لا شيء هنا يعتمد على أن أتذكّره.

هذا دليل ميداني لطريقة حماية FinyxWatt والخادم الذي يعمل عليه هذا الموقع: ست طبقات، كل واحدة مبنية على افتراض أن الطبقة التي فوقها قد سقطت بالفعل. كل إعداد هنا مأخوذ من الملفات الحقيقية، مختصرًا، بلا أسرار ولا أسماء خوادم. وحين تنتهي ستعرف كيف تجعل PostgreSQL ترفض قراءةً نسي كودك تصفيتها، وكيف تشغّل حاويات لا تكاد تستطيع شيئًا، وكيف تمنح هاتفًا هوية لا يمكن تزويرها، وكيف تثبت كل أسبوع أن نسختك الاحتياطية تُستعاد فعلًا.

وفي الطريق ثلاثة فخاخ: إعداد في PostgreSQL يعود سلسلة فارغة، وترويسة يستطيع أي أحد تزويرها لو انضمت حاوية واحدة إلى الشبكة الخطأ، وقيمة افتراضية لإعادة المحاولة تجعل نسخة تالفة تحتجز اختبارها ساعات.

6. الخادمجدار ناري لا يفتح إلا SSH وHTTP وHTTPS، ودخول SSH بالمفاتيح فقط، وتحديثات أمنية تلقائية
5. البوابة (Caddy)HTTPS، وترويسات الأمان، ومسارات إدارة مغلقة، وشهادات الهواتف
4. الحاوياتللقراءة فقط، بلا صلاحيات Linux، بشبكات داخلية، والأسرار ملفات
3. الـ APIرموز متحقَّق منها، والمحطة تُؤخذ من الرمز، لا من الطلب أبدًا
2. أدوار قاعدة البياناتلا مستخدم خارق، ولا تجاوز، ودفتر وسجل تدقيق للإضافة فقط
1. أمان الصفوفكل صف مربوط بعضوية نشطة في محطة المستخدم

ست طبقات بين الإنترنت والبيانات، من الخارج إلى الداخل. يبدأ هذا الدليل من الأسفل، بجوار البيانات. والنسخ الاحتياطية بجانب الطبقات كلها.

الطبقة 1: صفوف ترفض المحطة الخطأ

الحد المعتاد بين المستأجرين شرط WHERE يتكرر في كل استعلام. يصمد حتى يأتي استعلام كُتب على عجل فيُسقطه، والخطأ عندها صامت: الصفحة تعمل، لكنها تعرض أكثر مما ينبغي.

FinyxWatt تنقل الحد إلى داخل قاعدة البيانات. أمان الصفوف مفعّل ومُجبَر على 88 جدولًا من أصل 94 في ترحيلاتها (migrations). الجداول الستة الباقية تحمل قائمة الصلاحيات، وبيانات المخطط، وسجلات استيراد جرى مرة واحدة. وكل سياسة (policy) تتحقق من محطة الصف، ومن أن المستخدم عضو نشط فيها:

sql

ALTER TABLE invoices ENABLE ROW LEVEL SECURITY;
ALTER TABLE invoices FORCE ROW LEVEL SECURITY;

CREATE POLICY tenant_scope_api ON invoices FOR ALL TO platform_api
  USING (
    tenant_id = app_private.current_tenant_id()
    AND EXISTS (
      SELECT 1 FROM tenant_memberships m
      WHERE m.tenant_id   = app_private.current_tenant_id()
        AND m.identity_id = app_private.current_identity_id()
        AND m.status = 'active'
    )
  )
  WITH CHECK ( /* الشرط نفسه */ );

الترحيل الذي أضاف شرط العضوية يبدأ بسببه: "خطأ برمجي في المستقبل يجب ألا يحوّل هوية متحققًا منها من المستأجر A إلى المستأجر B لمجرد ضبط خاطئ لإعداد المعاملة". معرّف محطة خاطئ لن يجد عضوية نشطة، فيعود الاستعلام فارغًا.

ويضبط الـ API القيمتين في بداية كل معاملة (transaction)، من الرمز الذي تحقق منه:

async withTenant<T>(tenantId: string, identityId: string, callback: (trx: Transaction<Database>) => Promise<T>) {
  return this.db.transaction().execute(async (trx) => {
    await sql`select set_config('app.tenant_id', ${tenantId}, true)`.execute(trx)
    await sql`select set_config('app.identity_id', ${identityId}, true)`.execute(trx)
    return callback(trx)
  })
}

ثلاث تفاصيل تقرر هل ينجح هذا كله.

الـ true الأخيرة تحصر الإعداد في المعاملة. أما SET العادية فتبقى على الاتصال، فيسلّمه الـ pool إلى الطلب التالي وهو ما زال يشير إلى المحطة A.

السلسلة الفارغة هي الفخ الأول. على اتصال جديد، الإعداد الذي لم يُعرَّف قط يُقرأ NULL. أما على اتصال من الـ pool خدم طلبًا من قبل، فيُقرأ ''، و''::uuid يرمي خطأ. والدالة التي تستدعيها كل سياسة تعالج الحالتين:

sql

CREATE FUNCTION app_private.current_tenant_id() RETURNS uuid
LANGUAGE sql STABLE PARALLEL SAFE AS $function$
  SELECT nullif(current_setting('app.tenant_id', true), '')::uuid;
$function$;

وNULL لا يساوي شيئًا، فالطلب الذي يصل بلا سياق يرى صفر صفوف. يفشل مغلقًا (fail closed).

FORCE مهم لأن مالك الجدول يتخطى سياساته افتراضيًا، والمستخدم الخارق وأدوار BYPASSRLS تتخطاها دائمًا. وهذه مهمة الطبقة الثانية.

ويطبّق الـ CI كل الترحيلات على PostgreSQL جديدة، ويشغّل اختبارات SQL هجومية بدور الـ API نفسه. هذا قلب واحد منها، جاهز للنسخ:

sql

SET ROLE platform_api;
SET LOCAL app.tenant_id   = '<station A>';
SET LOCAL app.identity_id = '<an active member of station A>';

DO $test$
BEGIN
  IF (SELECT count(*) FROM customers) <> 1 THEN
    RAISE EXCEPTION 'RLS expected one station-A customer';
  END IF;

  BEGIN
    INSERT INTO customers (tenant_id, subscriber_number, display_name)
    VALUES ('<station B>', 'ILLEGAL', 'Cross-tenant write');
    RAISE EXCEPTION 'RLS accepted a cross-tenant write';
  EXCEPTION WHEN insufficient_privilege THEN NULL;
  END;
END $test$;

كل هذا يفترض أن الـ API يتصل بدور تنطبق عليه السياسات.

الطبقة 2: حسابات لا تستطيع إطفاءه

اتصل بصفة المالك دون FORCE، أو بمستخدم خارق، أو بدور BYPASSRLS، وتصير كل السياسات السابقة زينة.

قاعدة FinyxWatt تنشئ حساباتها عند أول تشغيل، "قبل أن يُسمح لصورة الـ API بالاتصال أصلًا"، بتعبير السكربت. مختصرًا، والسكربت الحقيقي يأخذ الأسماء من البيئة وكلمات المرور من ملفات سرية:

sql

CREATE ROLE migrator  LOGIN NOSUPERUSER NOCREATEDB CREATEROLE   NOREPLICATION NOBYPASSRLS;
CREATE ROLE api_login LOGIN NOSUPERUSER NOCREATEDB NOCREATEROLE NOREPLICATION NOBYPASSRLS;

ALTER DATABASE app OWNER TO migrator;
REVOKE CONNECT ON DATABASE app FROM PUBLIC;
GRANT  CONNECT ON DATABASE app TO migrator, api_login;

GRANT platform_api TO api_login;   -- الدور الذي كُتبت له كل السياسات

حساب الترحيل وحده يملك المخطط. لا يحمل أي حساب تشغيل كلمة مرور الترحيل، والـ API يعمل بـ RUN_MIGRATIONS: "false". وخمسة أدوار تشغيل تتقاسم العمل:

الدور	يستطيع	لا يستطيع
`platform_api`	بيانات المحطة عبر السياسات، والإضافة إلى الدفتر وسجل التدقيق	تعديل قيد في الدفتر أو حدث تدقيق، أو حذفه
`platform_worker`	تسليم الإشعارات ومهام الرسائل من الطابور	أن يتقاسم مع الـ API حسابه أو كلمة مروره
`platform_control`	لوحة تحكم المنصة	العمل دون هوية منصة في المعاملة
`platform_auditor`	قراءة سجل التدقيق وسجل التغييرات	كتابة أي شيء
`platform_sms_enrollment`	الرموز المؤقتة وطلبات الهواتف المعلّقة	رؤية مهام الرسائل أو الأجهزة أو سجلات التدقيق أو العملاء

والدفتر وسجل التدقيق يرفضان التعديل مرتين:

sql

GRANT SELECT, INSERT ON ledger_entries TO platform_api;   -- لا UPDATE ولا DELETE

CREATE FUNCTION app_private.prevent_ledger_mutation() RETURNS trigger
LANGUAGE plpgsql SECURITY INVOKER SET search_path = pg_catalog, public AS $function$
BEGIN
  RAISE EXCEPTION 'ledger entries are append-only; post a reversal entry instead'
    USING ERRCODE = 'integrity_constraint_violation';
END;
$function$;

CREATE TRIGGER ledger_entries_append_only
BEFORE UPDATE OR DELETE ON ledger_entries
FOR EACH ROW EXECUTE FUNCTION app_private.prevent_ledger_mutation();

قد يوسّع ترحيل لاحق صلاحية بالخطأ. يبقى الـ trigger رافضًا، ورسالته تخبر المطوّر التالي بما يفعله بدلًا من ذلك: القيود للإضافة فقط، والتصحيح يكون بقيد عكسي.

sql

-- حسابات تتخطى أمان الصفوف
SELECT rolname FROM pg_roles
WHERE rolcanlogin AND (rolsuper OR rolbypassrls);

-- جداول ليس عليها أمان صفوف مفعّل ومُجبَر معًا
SELECT relname FROM pg_class
WHERE relkind = 'r' AND relnamespace = 'public'::regnamespace
  AND NOT (relrowsecurity AND relforcerowsecurity);

الأدوار تحدد ما يحق للحساب فعله. أما المحطة التي يعمل باسمها فتأتي من رمز.

الطبقة 3: API لا يصدّق إلا ما تحقق منه

تسجّل FinyxWatt دخول المستخدمين عبر Keycloak. والـ API يتحقق من توقيع كل رمز، ومُصدِره، والجهة الموجَّه إليها، وصلاحيته الزمنية، مقابل المفاتيح التي ينشرها Keycloak:

this.jwks ??= createRemoteJWKSet(new URL(this.config.keycloakJwksUri))
const { payload } = await jwtVerify(token, this.jwks, {
  issuer: this.config.keycloakIssuer,
  audience: this.config.keycloakAudience,
})

ثم يقرأ الـ claim المتحقَّق منه azp ليعرف أي تطبيق حصل على الرمز. والتعليق فوق هذا الفحص هو درس الطبقة كله: "لا تقبل أبدًا ترويسة تحدد نوع التطبيق: يستطيع المتصل تزويرها ليلتفّ برمز أندرويد على مسار لا يقبل إلا الـ cookies".

والمحطة تتبع القاعدة نفسها. الـ API لا يقبل إلا عضويات الهوية المتحقق منها، ثم يعيد قراءة العضوية تحت RLS. والجلسات قصيرة، ورموزها لمرة واحدة:

json

"accessTokenLifespan": 300,
"revokeRefreshToken": true,
"refreshTokenMaxReuse": 0,
"bruteForceProtected": true,
"failureFactor": 5

رمز الوصول يعيش خمس دقائق. ورمز التحديث يعمل مرة واحدة، فالنسخة المسروقة منه تُستهلك لحظة يستخدمه أي من الطرفين. وخمس كلمات مرور خاطئة تجعل الحساب ينتظر.

حتى الآن كان المهاجم خطأً في كودي أنا. الطبقات التالية تفترض أنه صار داخل حاوية.

الطبقة 4: حاويات لا تكاد تستطيع شيئًا

يعمل هذا الموقع في حاوية Caddy واحدة، تعريفها هكذا:

yaml

web:
  image: caddy:2.10.2-alpine
  ports: ['80:80', '443:443', '443:443/udp']
  volumes:
    - ./Caddyfile:/etc/caddy/Caddyfile:ro
    - /srv/moghalis:/srv/moghalis:ro
    - caddy_data:/data
    - caddy_config:/config
  read_only: true
  tmpfs: [/tmp]
  cap_drop: [ALL]
  cap_add: [NET_BIND_SERVICE]
  security_opt: [no-new-privileges:true]
  mem_limit: 128m

لا شيء يُكتب خارج /tmp ووحدتي تخزين الشهادات، وكل صلاحيات Linux مسحوبة إلا ربط المنافذ المنخفضة، ولا عملية تستطيع رفع صلاحياتها، والذاكرة تقف عند 128 ميغابايت.

وFinyxWatt تشغّل عشرين خدمة، كلها بـ no-new-privileges، وبوابتها Caddy للقراءة فقط وبلا أي صلاحيات. والحماية الأقوى هي خريطة الشبكات:

yaml

networks:
  edge:
  application:   { internal: true }
  database:      { internal: true }
  observability: { internal: true }
  sms_gateway:   { internal: true }
  egress:

الشبكة internal لا طريق منها إلى الخارج، وكل خدمة لا تنضم إلا إلى ما تحتاجه:

الخدمة	الشبكات
Caddy، البوابة	edge، application، sms_gateway، observability
الـ API	application، database، egress، observability
بوابة الرسائل	sms_gateway، database
تسجيل الهواتف	application، database
واجهة الويب، وتخزين الملفات	application

البوابة لا طريق لها إلى قاعدة البيانات، وخدمات الصفوف الثلاثة الأخيرة لا طريق لها إلى الإنترنت.

تحتاج FinyxWatt في الإنتاج إلى 28 سرًا. كل سر ملف مستقل بقيمة عشوائية خاصة به، يُركَّب سرًّا من أسرار Docker في الحاويات التي تحتاجه فقط:

yaml

api:
  environment:
    DB_USER: ${PLATFORM_API_USER}
    DB_PASSWORD_FILE: /run/secrets/platform_api_password
  secrets:
    - platform_api_password

ودليل الأسرار يختصر القاعدة في جملة: "لا تضع الأسرار في وسائط سطر الأوامر، ولا في ملفات .env، ولا في سجل الطرفية، ولا في صور الحاويات، ولا في نظام إدارة الكود". متغير البيئة يظهر في docker inspect، أما الملف تحت /run/secrets فلا يوجد إلا حيث رُكِّب.

الطبقة 5: بوابة تجيب أقل

Caddy على خادم هذا الموقع يجدّد شهادات HTTPS، ويضيف هذه الترويسات إلى كل رد:

caddy

header {
	Strict-Transport-Security "max-age=31536000; includeSubDomains"
	X-Content-Type-Options "nosniff"
	X-Frame-Options "SAMEORIGIN"
	Referrer-Policy "strict-origin-when-cross-origin"
	Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=()"
	-Server
}

وبوابة FinyxWatt تغلق أيضًا كل ما لا تخدمه:

caddy

{
	admin off
}

(restricted_console) {
	@outside_trusted_networks not remote_ip {$ADMIN_TRUSTED_CIDRS}
	respond @outside_trusted_networks 403
	basic_auth {
		{$OBSERVABILITY_USER} {$OBSERVABILITY_PASSWORD_HASH}
	}
}

admin off يطفئ واجهة الإدارة الخاصة بـ Caddy نفسه. ولوحات المراقبة لا تجيب إلا من شبكات موثوقة، ثم تطلب كلمة مرور لا يحفظ الخادم منها إلا تجزئة bcrypt. والمسار /metrics يعيد 404 من الإنترنت، ومسار تسجيل الهواتف العام لا يقبل أكثر من 32 كيلوبايت، لأنه لا يستقبل ملفًا أبدًا. وكل ترويسة أمان تأتي من مكان واحد: الـ API يضع X-Frame-Options بنفسه، فتتركها كتلة الـ API في Caddy.

أما أمتع مهام البوابة فهي فحص جواز سفر كل هاتف يرسل الفواتير.

جواز سفر لكل هاتف

ترسل FinyxWatt فاتورة كل عميل برسالة قصيرة من هواتف أندرويد مخصصة في المحطة. والهاتف الذي يرسل باسم محطة يحتاج أكثر من كلمة مرور، فيحصل على شهادة عميل (client certificate).

على الهاتفيُنشأ مفتاح داخل Android Keystore ولا يغادره أبدًا
إلى خدمة التسجيلرمز لمرة واحدة وإثبات امتلاك المفتاح ينشئان طلبًا معلّقًا، لا أكثر
مدير ثانٍ يراجعمنشئ الرمز لا يحق له الاعتماد، والاعتماد يربط شهادة بالمفتاح المُثبَت
عودة إلى الهاتفتُثبَّت الشهادة
كل اتصالCaddy يشترط الشهادة ويتحقق منها، ثم يكتب ترويسة البصمة بنفسه

كيف يكسب هاتف الرسائل شهادته. المفتاح الخاص لجهة الإصدار لا يلمس الخادم أبدًا.

قاعدة البيانات لا تحفظ إلا HMAC للرمز، مصنوعًا بقيمة سرية (pepper)، والمخطط نفسه يفرض الحدود:

sql

-- HMAC-SHA-256(code-id || secret), never the raw enrollment code.
code_digest  bytea NOT NULL CHECK (octet_length(code_digest) = 32),
expires_at   timestamptz NOT NULL,
max_attempts smallint NOT NULL DEFAULT 5 CHECK (max_attempts BETWEEN 1 AND 10),
attempts     smallint NOT NULL DEFAULT 0 CHECK (attempts BETWEEN 0 AND 10),
CONSTRAINT sms_device_enrollment_codes_attempts_bound CHECK (attempts <= max_attempts),
CONSTRAINT sms_device_enrollment_codes_expiry CHECK (expires_at > created_at)

والاعتماد يمر عبر الـ API الرئيسي، الذي يرفض منشئ الرمز بالخطأ SMS_ENROLLMENT_SELF_APPROVAL_FORBIDDEN، ويربط شهادة من جهة إصدار خاصة يطابق مفتاحها العام المفتاحَ الذي أثبت الهاتف امتلاكه. ومن بعدها:

caddy

tls {
	client_auth {
		mode require_and_verify
		trust_pool file /run/secrets/sms_device_ca_pem
	}
}
reverse_proxy sms-gateway:8081 {
	header_up X-Verified-Client-Certificate-Fingerprint {tls_client_fingerprint}
}

وهنا الفخ الثاني. بوابة الرسائل تصدّق ترويسة البصمة دون سؤال، وهذا آمن لسبب واحد: البوابة تقع على شبكة داخلية لا ينضم إليها إلا Caddy، وCaddy يكتب الترويسة فوق أي قيمة سابقة بعد أن يتحقق من الشهادة. وكود البوابة نفسه يشرح كيف يُكسر هذا: "لا تنشر منفذ حاوية البوابة، ولا تضف حاويات عشوائية إلى تلك الشبكة؛ أيٌّ منهما يجعل هذه الترويسة قابلة للتزوير". سطر ports: واحد يُضاف لتجربة سريعة، ويصير بوسع أي أحد أن يرسل الترويسة بنفسه.

والـ proxy يخفي فخًا آخر. كل طلب يصل إلى البوابة بعنوان Caddy، فحدّ الطلبات لكل IP سيعطي الهواتف كلها ميزانية واحدة مشتركة. لذلك تبني البوابة حدّها على الشهادة المتحقق منها:

await app.register(fastifyRateLimit, {
  max: 120,
  timeWindow: '1 minute',
  keyGenerator: (request) => {
    const fingerprint = request.headers['x-verified-client-certificate-fingerprint']
    const normalized = typeof fingerprint === 'string' ? fingerprint.trim().toLowerCase().replaceAll(':', '') : ''
    return /^[0-9a-f]{64}$/.test(normalized) ? `device:${normalized}` : `addr:${request.ip}`
  },
})

والمفتاح الخاص لجهة الإصدار يبقى خارج الاتصال، وشهادة كل هاتف تُلغى حين يُلغى جهازه.

الطبقة 6: خادم لا يغلق الباب في وجهك

جُهّز خادم هذا الموقع بسكربت واحد، والجزء الخاص بـ SSH فيه حريص على الترتيب:

bash

if [ -s "/home/$USER_NAME/.ssh/authorized_keys" ]; then
  cat >/etc/ssh/sshd_config.d/10-moghalis.conf <<'EOF'
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
EOF
  sshd -t && systemctl reload ssh
else
  echo "!! No SSH key for $USER_NAME yet: password login left ON."
fi

ufw default deny incoming
ufw allow OpenSSH
ufw allow 80/tcp
ufw allow 443/tcp
ufw allow 443/udp
ufw --force enable

الدخول بكلمة المرور لا يُطفأ إلا إن وُجد مفتاح، وSSH لا يُعاد تحميله إلا إن قبل sshd -t الإعداد، والجدار الناري يسمح بـ SSH قبل أن يُرفع. اعكس أيًّا من الثلاثة على VPS جديد، وستكون محطتك التالية شاشة الإنقاذ عند مزوّد الخادم.

ست طبقات، كل واحدة تفترض أن التي فوقها تسقط. والنسخة الاحتياطية تفترض أنها سقطت كلها.

بجانب الطبقات: نسخة احتياطية تثبت أنها تُستعاد

تؤرشف PostgreSQL في FinyxWatt سجل الكتابة المسبق (WAL) كل خمس دقائق على الأقل، وتأخذ نسخة أساسية كاملة كل ليلة عبر WAL-G، وإصدار WAL-G نفسه مثبّت ومتحقق من بصمته. كل ملف يُضغط ويُشفَّر قبل أن يُكتب. وجهاز مكتب المالك يسحب الملفات الجديدة كل أربع ساعات ويحتفظ بخمسة وأربعين يومًا منها.

مفتاح التشفير هو النسخة الاحتياطية نفسها: إن ضاع صار كل ملف ضجيجًا. لذلك هو مختوم مع بقية أسرار الخادم في ملف محمي بكلمة سر، على ذاكرة USB وفي مكان ثانٍ، وكلمة السر محفوظة بعيدًا عنهما.

ولا شيء من ذلك يثبت شيئًا حتى تنجح استعادة. كل يوم جمعة يستعيد سكربت أحدث نسخة أساسية وكل سجل مؤرشف بعدها في وحدة تخزين مؤقتة. مختصرًا:

bash

timeout --kill-after=60 2700 docker run --rm --network none --name "$name" \
  -e PITR_STORAGE_MODE=local -e WALG_DOWNLOAD_FILE_RETRIES=2 \
  -v "$name:/restore" \
  -v "$repository:/local-pitr:ro" \
  -v "$key:/run/secrets/pitr_encryption_key:ro" \
  --entrypoint bash "$image" /restore-check.sh

وفي الداخل، تُضاف هذه الأسطر إلى إعداد النسخة قبل أن تبدأ PostgreSQL:

bash

cat >> /restore/data/postgresql.auto.conf <<'CONF'
restore_command = '/usr/local/bin/pitr-walg wal-fetch %f %p'
archive_mode = off
listen_addresses = ''
CONF
touch /restore/data/recovery.signal

كل سطر حارس. بلا شبكة، فلا تلمس النسخة قاعدة البيانات الحية. والمستودع والمفتاح للقراءة فقط. لا أرشفة، ولا منفذ يستمع. و$image يُقرأ من حاوية قاعدة البيانات الحية، فيستعيد الفحص بالصورة نفسها التي يعمل بها الإنتاج. وحين تنتهي الاستعادة، يعدّ ما عاد:

sql

SELECT json_build_object(
  'migrations',   (SELECT count(*) FROM schema_migrations),
  'stations',     (SELECT count(*) FROM tenants),
  'customers',    (SELECT count(*) FROM customers),
  'bills',        (SELECT count(*) FROM invoices),
  'receipts',     (SELECT count(*) FROM payments),
  'newestChange', (SELECT max(changed_at) FROM change_log));

الأعداد تقول إن النسخة تحمل ما ينبغي، وأحدث تغيير يقول كم هي حديثة. ثم يُحذف كل شيء، أيًّا كانت النتيجة. وإن فشل الفحص، أو مرت تسعة أيام بلا فحص، يصلني تنبيه في تطبيق المطوّر.

والآن الفخ الثالث، وسبب WALG_DOWNLOAD_FILE_RETRIES=2. يعيد WAL-G محاولة الملف الذي يتعذر عليه قراءته 15 مرة، تفصل بينها دقائق. وجّهه إلى نسخة تالفة أو لا يمكن فك تشفيرها، ولن يفشل الفحص. سينتظر، لساعات. محاولتان وسقف 45 دقيقة يحوّلان هذا الانتظار إلى فشل واضح مع سببه.

النسخة المشفرةأحدث نسخة أساسية وكل ملفات WAL بعدها، للقراءة فقط
حاوية مختومةبلا شبكة، ولا أرشفة، ولا منفذ يستمع، و45 دقيقة على الأكثر
استعادة PostgreSQLتُبنى القاعدة بالصورة التي يعمل بها الإنتاج
عدّ ما عادالترحيلات والمحطات والعملاء والفواتير والسندات وأحدث تغيير
التنظيفتُحذف الحاوية ووحدة التخزين، والنتيجة تذهب إلى المراقب

فحص الاستعادة كل جمعة. الفشل، أو مرور تسعة أيام بلا فحص، يطلق تنبيهًا.

ومراقب يعمل كل عشر دقائق ويبلّغ عما يكسر النسخ الاحتياطية بصمت: قرص امتلأ 85%، وخدمة توقفت، ونسخة كاملة أقدم من 26 ساعة، وأرشفة WAL متعثرة، وجهاز مكتب لم يسحب النسخ منذ ثلاثة أيام، وشهادة أمان تقترب من انتهائها.

البوابة أمام كل إصدار

الطبقات تحمي النظام وهو يعمل. والبوابة تحميه من الإصدار القادم.

فحصٌ للمستودع يُفشل البناء عند وجود مفاتيح خاصة، أو رموز وصول، أو رموز JWT، أو رابط قاعدة بيانات فيه كلمة مرور، أو بريد إلكتروني أو رقم هاتف حقيقي، أو أي ملف .env أو secrets/ متتبَّع:

['private key material', /-----BEGIN(?: [A-Z]+)? PRIVATE KEY-----/],
['GitHub access token', /\bgh[pousr]_[A-Za-z0-9_]{30,}\b/],
['database URI with embedded password', /\bpostgres(?:ql)?:\/\/[^\s:@/${]+:[^\s@/${]{8,}@/i],

وهو يجمع الملفات بـ git ls-files --cached --others --exclude-standard، فإن شغّلته محليًا التقط الملف قبل أن تضيفه إلى Git.

ثم يشغّل الـ CI كل الترحيلات على PostgreSQL جديدة مع اختبارات عزل المحطات، واختبارات الخلفية، واختبارات التكامل بدور قاعدة البيانات المقيّد، وnpm audit --omit=dev --audit-level=high. والنشر التلقائي ينتظر ذلك كله:

yaml

on:
  workflow_run:
    workflows: [Independent Platform CI]
    types: [completed]
    branches: [main]

concurrency:
  group: production-deploy
  cancel-in-progress: false

jobs:
  deploy:
    if: github.event.workflow_run.conclusion == 'success'
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.event.workflow_run.head_sha }}

في هذه الأسطر ثلاثة فخاخ. workflow_run ينطلق حين يكتمل الـ CI، نجح أو فشل، فبدون شرط if ينشر البناء الأحمر. وسحب main بدل head_sha قد ينشر commit لم يختبره الـ CI قط. والنشر الذي يُلغى في منتصفه يترك خادمًا نصف مُرحَّل. والـ job يثبّت بصمة مفتاح الخادم قبل أول أمر SSH.

هاجم نظامك بنفسك، على الورق

مراجعة مكتوبة هاجمت FinyxWatt عبر كودها وبطلبات سلبية لا تغيّر شيئًا على الخوادم الحية، وسجّلت كل نتيجة مع الملف الذي يثبتها:

المحاولة	ما الذي يوقفها
رمز مزوّر: `alg: none`، أو مُصدِر آخر	`jose`، والمفاتيح المنشورة، والمُصدِر، والجهة الموجَّه إليها، و`azp`
العمل باسم محطة أخرى عبر ترويسة العضوية	عضويات الهوية المتحقق منها فقط، تُعاد قراءتها تحت RLS
قراءة سجل تغييرات محطة أخرى	أمان الصفوف على سجل التغييرات
طلب POST من موقع آخر على جلسة الموقع	فحص الأصل (origin) وملفات تعريف `SameSite=Strict`
انعكاس CORS بترويسة `Origin` معادية	لا `Access-Control-Allow-Origin` في الرد، بفحص حي
ترويسة بصمة شهادة مزوّرة	منفذ غير منشور، وCaddy يكتب الترويسة فوقها
تخمين رمز ربط الهاتف	خمس محاولات، وHMAC بقيمة سرية، ومدة صلاحية، وقفل للصف
الوصول إلى `/metrics` أو لوحة Keycloak من الخارج	404 و403، بفحص حي

قائمة الفحص

أمان الصفوف مُجبَر على كل جدول للمستأجرين، وسياساته تتحقق من عضوية نشطة.
سياق المستأجر لكل معاملة بـ set_config(..., true)، من الرمز، ويُقرأ عبر nullif.
لا حساب تطبيق هو المالك أو مستخدم خارق أو BYPASSRLS، وحساب لكل مهمة.
جداول الدفتر والتدقيق بلا صلاحيات UPDATE أو DELETE، ومعها trigger يرفضهما.
الأسرار ملفات تُركَّب حيث يلزم فقط، والـ CI يفشل عند المفاتيح والرموز وملفات .env المتتبَّعة.
حاويات للقراءة فقط، بلا صلاحيات، بحد للذاكرة، على شبكات داخلية.
ترويسات الهوية لا تُصدَّق إلا على شبكة مغلقة، وحدود الطلبات مبنية على تلك الهوية.
نسخ احتياطية مشفرة، ومفتاحها بعيد عنها، ونسخة خارج الخادم، وفحص استعادة بحد زمني وتنبيه.
لا نشر إلا بعد CI أخضر، ومن الـ commit المختبَر، ولا إلغاء في المنتصف.

لا طبقة من هذه ذكية وحدها. القوة في الافتراض الذي تحتها كلها: الطبقة التي فوقك سقطت بالفعل، وعليك أن تصمد مع ذلك. اكتب هذا الافتراض في إعداداتك، ويصير اليوم الذي تسقط فيه إحداها يومًا عاديًا.

وإن كنت تفضّل أن يتولى أحد هذا كله لنظامك، فهذا ما تغطيه الاستضافة والدعم.

لذلك لا شيء هنا يعتمد على أن أتذكّره.

6. الخادمجدار ناري لا يفتح إلا SSH وHTTP وHTTPS، ودخول SSH بالمفاتيح فقط، وتحديثات أمنية تلقائية
5. البوابة (Caddy)HTTPS، وترويسات الأمان، ومسارات إدارة مغلقة، وشهادات الهواتف
4. الحاوياتللقراءة فقط، بلا صلاحيات Linux، بشبكات داخلية، والأسرار ملفات
3. الـ APIرموز متحقَّق منها، والمحطة تُؤخذ من الرمز، لا من الطلب أبدًا
2. أدوار قاعدة البياناتلا مستخدم خارق، ولا تجاوز، ودفتر وسجل تدقيق للإضافة فقط
1. أمان الصفوفكل صف مربوط بعضوية نشطة في محطة المستخدم

الطبقة 1: صفوف ترفض المحطة الخطأ

sql

ALTER TABLE invoices ENABLE ROW LEVEL SECURITY;
ALTER TABLE invoices FORCE ROW LEVEL SECURITY;

CREATE POLICY tenant_scope_api ON invoices FOR ALL TO platform_api
  USING (
    tenant_id = app_private.current_tenant_id()
    AND EXISTS (
      SELECT 1 FROM tenant_memberships m
      WHERE m.tenant_id   = app_private.current_tenant_id()
        AND m.identity_id = app_private.current_identity_id()
        AND m.status = 'active'
    )
  )
  WITH CHECK ( /* الشرط نفسه */ );

ويضبط الـ API القيمتين في بداية كل معاملة (transaction)، من الرمز الذي تحقق منه:

async withTenant<T>(tenantId: string, identityId: string, callback: (trx: Transaction<Database>) => Promise<T>) {
  return this.db.transaction().execute(async (trx) => {
    await sql`select set_config('app.tenant_id', ${tenantId}, true)`.execute(trx)
    await sql`select set_config('app.identity_id', ${identityId}, true)`.execute(trx)
    return callback(trx)
  })
}

ثلاث تفاصيل تقرر هل ينجح هذا كله.

sql

CREATE FUNCTION app_private.current_tenant_id() RETURNS uuid
LANGUAGE sql STABLE PARALLEL SAFE AS $function$
  SELECT nullif(current_setting('app.tenant_id', true), '')::uuid;
$function$;

وNULL لا يساوي شيئًا، فالطلب الذي يصل بلا سياق يرى صفر صفوف. يفشل مغلقًا (fail closed).

sql

SET ROLE platform_api;
SET LOCAL app.tenant_id   = '<station A>';
SET LOCAL app.identity_id = '<an active member of station A>';

DO $test$
BEGIN
  IF (SELECT count(*) FROM customers) <> 1 THEN
    RAISE EXCEPTION 'RLS expected one station-A customer';
  END IF;

  BEGIN
    INSERT INTO customers (tenant_id, subscriber_number, display_name)
    VALUES ('<station B>', 'ILLEGAL', 'Cross-tenant write');
    RAISE EXCEPTION 'RLS accepted a cross-tenant write';
  EXCEPTION WHEN insufficient_privilege THEN NULL;
  END;
END $test$;

كل هذا يفترض أن الـ API يتصل بدور تنطبق عليه السياسات.

الطبقة 2: حسابات لا تستطيع إطفاءه

اتصل بصفة المالك دون FORCE، أو بمستخدم خارق، أو بدور BYPASSRLS، وتصير كل السياسات السابقة زينة.

sql

CREATE ROLE migrator  LOGIN NOSUPERUSER NOCREATEDB CREATEROLE   NOREPLICATION NOBYPASSRLS;
CREATE ROLE api_login LOGIN NOSUPERUSER NOCREATEDB NOCREATEROLE NOREPLICATION NOBYPASSRLS;

ALTER DATABASE app OWNER TO migrator;
REVOKE CONNECT ON DATABASE app FROM PUBLIC;
GRANT  CONNECT ON DATABASE app TO migrator, api_login;

GRANT platform_api TO api_login;   -- الدور الذي كُتبت له كل السياسات

الدور	يستطيع	لا يستطيع
`platform_api`	بيانات المحطة عبر السياسات، والإضافة إلى الدفتر وسجل التدقيق	تعديل قيد في الدفتر أو حدث تدقيق، أو حذفه
`platform_worker`	تسليم الإشعارات ومهام الرسائل من الطابور	أن يتقاسم مع الـ API حسابه أو كلمة مروره
`platform_control`	لوحة تحكم المنصة	العمل دون هوية منصة في المعاملة
`platform_auditor`	قراءة سجل التدقيق وسجل التغييرات	كتابة أي شيء
`platform_sms_enrollment`	الرموز المؤقتة وطلبات الهواتف المعلّقة	رؤية مهام الرسائل أو الأجهزة أو سجلات التدقيق أو العملاء

والدفتر وسجل التدقيق يرفضان التعديل مرتين:

sql

GRANT SELECT, INSERT ON ledger_entries TO platform_api;   -- لا UPDATE ولا DELETE

CREATE FUNCTION app_private.prevent_ledger_mutation() RETURNS trigger
LANGUAGE plpgsql SECURITY INVOKER SET search_path = pg_catalog, public AS $function$
BEGIN
  RAISE EXCEPTION 'ledger entries are append-only; post a reversal entry instead'
    USING ERRCODE = 'integrity_constraint_violation';
END;
$function$;

CREATE TRIGGER ledger_entries_append_only
BEFORE UPDATE OR DELETE ON ledger_entries
FOR EACH ROW EXECUTE FUNCTION app_private.prevent_ledger_mutation();

sql

-- حسابات تتخطى أمان الصفوف
SELECT rolname FROM pg_roles
WHERE rolcanlogin AND (rolsuper OR rolbypassrls);

-- جداول ليس عليها أمان صفوف مفعّل ومُجبَر معًا
SELECT relname FROM pg_class
WHERE relkind = 'r' AND relnamespace = 'public'::regnamespace
  AND NOT (relrowsecurity AND relforcerowsecurity);

الأدوار تحدد ما يحق للحساب فعله. أما المحطة التي يعمل باسمها فتأتي من رمز.

الطبقة 3: API لا يصدّق إلا ما تحقق منه

this.jwks ??= createRemoteJWKSet(new URL(this.config.keycloakJwksUri))
const { payload } = await jwtVerify(token, this.jwks, {
  issuer: this.config.keycloakIssuer,
  audience: this.config.keycloakAudience,
})

json

"accessTokenLifespan": 300,
"revokeRefreshToken": true,
"refreshTokenMaxReuse": 0,
"bruteForceProtected": true,
"failureFactor": 5

حتى الآن كان المهاجم خطأً في كودي أنا. الطبقات التالية تفترض أنه صار داخل حاوية.

الطبقة 4: حاويات لا تكاد تستطيع شيئًا

يعمل هذا الموقع في حاوية Caddy واحدة، تعريفها هكذا:

yaml

web:
  image: caddy:2.10.2-alpine
  ports: ['80:80', '443:443', '443:443/udp']
  volumes:
    - ./Caddyfile:/etc/caddy/Caddyfile:ro
    - /srv/moghalis:/srv/moghalis:ro
    - caddy_data:/data
    - caddy_config:/config
  read_only: true
  tmpfs: [/tmp]
  cap_drop: [ALL]
  cap_add: [NET_BIND_SERVICE]
  security_opt: [no-new-privileges:true]
  mem_limit: 128m

yaml

networks:
  edge:
  application:   { internal: true }
  database:      { internal: true }
  observability: { internal: true }
  sms_gateway:   { internal: true }
  egress:

الشبكة internal لا طريق منها إلى الخارج، وكل خدمة لا تنضم إلا إلى ما تحتاجه:

الخدمة	الشبكات
Caddy، البوابة	edge، application، sms_gateway، observability
الـ API	application، database، egress، observability
بوابة الرسائل	sms_gateway، database
تسجيل الهواتف	application، database
واجهة الويب، وتخزين الملفات	application

البوابة لا طريق لها إلى قاعدة البيانات، وخدمات الصفوف الثلاثة الأخيرة لا طريق لها إلى الإنترنت.

yaml

api:
  environment:
    DB_USER: ${PLATFORM_API_USER}
    DB_PASSWORD_FILE: /run/secrets/platform_api_password
  secrets:
    - platform_api_password

الطبقة 5: بوابة تجيب أقل

Caddy على خادم هذا الموقع يجدّد شهادات HTTPS، ويضيف هذه الترويسات إلى كل رد:

caddy

header {
	Strict-Transport-Security "max-age=31536000; includeSubDomains"
	X-Content-Type-Options "nosniff"
	X-Frame-Options "SAMEORIGIN"
	Referrer-Policy "strict-origin-when-cross-origin"
	Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=()"
	-Server
}

وبوابة FinyxWatt تغلق أيضًا كل ما لا تخدمه:

caddy

{
	admin off
}

(restricted_console) {
	@outside_trusted_networks not remote_ip {$ADMIN_TRUSTED_CIDRS}
	respond @outside_trusted_networks 403
	basic_auth {
		{$OBSERVABILITY_USER} {$OBSERVABILITY_PASSWORD_HASH}
	}
}

أما أمتع مهام البوابة فهي فحص جواز سفر كل هاتف يرسل الفواتير.

جواز سفر لكل هاتف

على الهاتفيُنشأ مفتاح داخل Android Keystore ولا يغادره أبدًا
إلى خدمة التسجيلرمز لمرة واحدة وإثبات امتلاك المفتاح ينشئان طلبًا معلّقًا، لا أكثر
مدير ثانٍ يراجعمنشئ الرمز لا يحق له الاعتماد، والاعتماد يربط شهادة بالمفتاح المُثبَت
عودة إلى الهاتفتُثبَّت الشهادة
كل اتصالCaddy يشترط الشهادة ويتحقق منها، ثم يكتب ترويسة البصمة بنفسه

كيف يكسب هاتف الرسائل شهادته. المفتاح الخاص لجهة الإصدار لا يلمس الخادم أبدًا.

قاعدة البيانات لا تحفظ إلا HMAC للرمز، مصنوعًا بقيمة سرية (pepper)، والمخطط نفسه يفرض الحدود:

sql

-- HMAC-SHA-256(code-id || secret), never the raw enrollment code.
code_digest  bytea NOT NULL CHECK (octet_length(code_digest) = 32),
expires_at   timestamptz NOT NULL,
max_attempts smallint NOT NULL DEFAULT 5 CHECK (max_attempts BETWEEN 1 AND 10),
attempts     smallint NOT NULL DEFAULT 0 CHECK (attempts BETWEEN 0 AND 10),
CONSTRAINT sms_device_enrollment_codes_attempts_bound CHECK (attempts <= max_attempts),
CONSTRAINT sms_device_enrollment_codes_expiry CHECK (expires_at > created_at)

caddy

tls {
	client_auth {
		mode require_and_verify
		trust_pool file /run/secrets/sms_device_ca_pem
	}
}
reverse_proxy sms-gateway:8081 {
	header_up X-Verified-Client-Certificate-Fingerprint {tls_client_fingerprint}
}

await app.register(fastifyRateLimit, {
  max: 120,
  timeWindow: '1 minute',
  keyGenerator: (request) => {
    const fingerprint = request.headers['x-verified-client-certificate-fingerprint']
    const normalized = typeof fingerprint === 'string' ? fingerprint.trim().toLowerCase().replaceAll(':', '') : ''
    return /^[0-9a-f]{64}$/.test(normalized) ? `device:${normalized}` : `addr:${request.ip}`
  },
})

والمفتاح الخاص لجهة الإصدار يبقى خارج الاتصال، وشهادة كل هاتف تُلغى حين يُلغى جهازه.

الطبقة 6: خادم لا يغلق الباب في وجهك

جُهّز خادم هذا الموقع بسكربت واحد، والجزء الخاص بـ SSH فيه حريص على الترتيب:

bash

if [ -s "/home/$USER_NAME/.ssh/authorized_keys" ]; then
  cat >/etc/ssh/sshd_config.d/10-moghalis.conf <<'EOF'
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
EOF
  sshd -t && systemctl reload ssh
else
  echo "!! No SSH key for $USER_NAME yet: password login left ON."
fi

ufw default deny incoming
ufw allow OpenSSH
ufw allow 80/tcp
ufw allow 443/tcp
ufw allow 443/udp
ufw --force enable

ست طبقات، كل واحدة تفترض أن التي فوقها تسقط. والنسخة الاحتياطية تفترض أنها سقطت كلها.

بجانب الطبقات: نسخة احتياطية تثبت أنها تُستعاد

bash

timeout --kill-after=60 2700 docker run --rm --network none --name "$name" \
  -e PITR_STORAGE_MODE=local -e WALG_DOWNLOAD_FILE_RETRIES=2 \
  -v "$name:/restore" \
  -v "$repository:/local-pitr:ro" \
  -v "$key:/run/secrets/pitr_encryption_key:ro" \
  --entrypoint bash "$image" /restore-check.sh

وفي الداخل، تُضاف هذه الأسطر إلى إعداد النسخة قبل أن تبدأ PostgreSQL:

bash

cat >> /restore/data/postgresql.auto.conf <<'CONF'
restore_command = '/usr/local/bin/pitr-walg wal-fetch %f %p'
archive_mode = off
listen_addresses = ''
CONF
touch /restore/data/recovery.signal

sql

SELECT json_build_object(
  'migrations',   (SELECT count(*) FROM schema_migrations),
  'stations',     (SELECT count(*) FROM tenants),
  'customers',    (SELECT count(*) FROM customers),
  'bills',        (SELECT count(*) FROM invoices),
  'receipts',     (SELECT count(*) FROM payments),
  'newestChange', (SELECT max(changed_at) FROM change_log));

النسخة المشفرةأحدث نسخة أساسية وكل ملفات WAL بعدها، للقراءة فقط
حاوية مختومةبلا شبكة، ولا أرشفة، ولا منفذ يستمع، و45 دقيقة على الأكثر
استعادة PostgreSQLتُبنى القاعدة بالصورة التي يعمل بها الإنتاج
عدّ ما عادالترحيلات والمحطات والعملاء والفواتير والسندات وأحدث تغيير
التنظيفتُحذف الحاوية ووحدة التخزين، والنتيجة تذهب إلى المراقب

فحص الاستعادة كل جمعة. الفشل، أو مرور تسعة أيام بلا فحص، يطلق تنبيهًا.

البوابة أمام كل إصدار

الطبقات تحمي النظام وهو يعمل. والبوابة تحميه من الإصدار القادم.

['private key material', /-----BEGIN(?: [A-Z]+)? PRIVATE KEY-----/],
['GitHub access token', /\bgh[pousr]_[A-Za-z0-9_]{30,}\b/],
['database URI with embedded password', /\bpostgres(?:ql)?:\/\/[^\s:@/${]+:[^\s@/${]{8,}@/i],

وهو يجمع الملفات بـ git ls-files --cached --others --exclude-standard، فإن شغّلته محليًا التقط الملف قبل أن تضيفه إلى Git.

yaml

on:
  workflow_run:
    workflows: [Independent Platform CI]
    types: [completed]
    branches: [main]

concurrency:
  group: production-deploy
  cancel-in-progress: false

jobs:
  deploy:
    if: github.event.workflow_run.conclusion == 'success'
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.event.workflow_run.head_sha }}

هاجم نظامك بنفسك، على الورق

المحاولة	ما الذي يوقفها
رمز مزوّر: `alg: none`، أو مُصدِر آخر	`jose`، والمفاتيح المنشورة، والمُصدِر، والجهة الموجَّه إليها، و`azp`
العمل باسم محطة أخرى عبر ترويسة العضوية	عضويات الهوية المتحقق منها فقط، تُعاد قراءتها تحت RLS
قراءة سجل تغييرات محطة أخرى	أمان الصفوف على سجل التغييرات
طلب POST من موقع آخر على جلسة الموقع	فحص الأصل (origin) وملفات تعريف `SameSite=Strict`
انعكاس CORS بترويسة `Origin` معادية	لا `Access-Control-Allow-Origin` في الرد، بفحص حي
ترويسة بصمة شهادة مزوّرة	منفذ غير منشور، وCaddy يكتب الترويسة فوقها
تخمين رمز ربط الهاتف	خمس محاولات، وHMAC بقيمة سرية، ومدة صلاحية، وقفل للصف
الوصول إلى `/metrics` أو لوحة Keycloak من الخارج	404 و403، بفحص حي

قائمة الفحص

أمان الصفوف مُجبَر على كل جدول للمستأجرين، وسياساته تتحقق من عضوية نشطة.
سياق المستأجر لكل معاملة بـ set_config(..., true)، من الرمز، ويُقرأ عبر nullif.
لا حساب تطبيق هو المالك أو مستخدم خارق أو BYPASSRLS، وحساب لكل مهمة.
جداول الدفتر والتدقيق بلا صلاحيات UPDATE أو DELETE، ومعها trigger يرفضهما.
الأسرار ملفات تُركَّب حيث يلزم فقط، والـ CI يفشل عند المفاتيح والرموز وملفات .env المتتبَّعة.
حاويات للقراءة فقط، بلا صلاحيات، بحد للذاكرة، على شبكات داخلية.
ترويسات الهوية لا تُصدَّق إلا على شبكة مغلقة، وحدود الطلبات مبنية على تلك الهوية.
نسخ احتياطية مشفرة، ومفتاحها بعيد عنها، ونسخة خارج الخادم، وفحص استعادة بحد زمني وتنبيه.
لا نشر إلا بعد CI أخضر، ومن الـ commit المختبَر، ولا إلغاء في المنتصف.

وإن كنت تفضّل أن يتولى أحد هذا كله لنظامك، فهذا ما تغطيه الاستضافة والدعم.

#الطبقة 1: صفوف ترفض المحطة الخطأ

#الطبقة 2: حسابات لا تستطيع إطفاءه

#الطبقة 3: API لا يصدّق إلا ما تحقق منه

#الطبقة 4: حاويات لا تكاد تستطيع شيئًا

#الطبقة 5: بوابة تجيب أقل

#جواز سفر لكل هاتف

#الطبقة 6: خادم لا يغلق الباب في وجهك

#بجانب الطبقات: نسخة احتياطية تثبت أنها تُستعاد

#البوابة أمام كل إصدار

#هاجم نظامك بنفسك، على الورق

#قائمة الفحص

اقرأ أيضًا

372 اختبارًا ناجحًا، ولا فاتورة بيع واحدة تصل إلى الدفتر

إيصال عربي على طابعة حرارية، وخمسة بايتات التهمت الرول كله

لماذا لم تمنع مفاتيح idempotency تكرار سند واحد 105 مرات؟

#الطبقة 1: صفوف ترفض المحطة الخطأ

#الطبقة 2: حسابات لا تستطيع إطفاءه

#الطبقة 3: API لا يصدّق إلا ما تحقق منه

#الطبقة 4: حاويات لا تكاد تستطيع شيئًا

#الطبقة 5: بوابة تجيب أقل

#جواز سفر لكل هاتف

#الطبقة 6: خادم لا يغلق الباب في وجهك

#بجانب الطبقات: نسخة احتياطية تثبت أنها تُستعاد

#البوابة أمام كل إصدار

#هاجم نظامك بنفسك، على الورق

#قائمة الفحص

الطبقة 1: صفوف ترفض المحطة الخطأ

الطبقة 2: حسابات لا تستطيع إطفاءه

الطبقة 3: API لا يصدّق إلا ما تحقق منه

الطبقة 4: حاويات لا تكاد تستطيع شيئًا

الطبقة 5: بوابة تجيب أقل

جواز سفر لكل هاتف

الطبقة 6: خادم لا يغلق الباب في وجهك

بجانب الطبقات: نسخة احتياطية تثبت أنها تُستعاد

البوابة أمام كل إصدار

هاجم نظامك بنفسك، على الورق

قائمة الفحص

الطبقة 1: صفوف ترفض المحطة الخطأ

الطبقة 2: حسابات لا تستطيع إطفاءه

الطبقة 3: API لا يصدّق إلا ما تحقق منه

الطبقة 4: حاويات لا تكاد تستطيع شيئًا

الطبقة 5: بوابة تجيب أقل

جواز سفر لكل هاتف

الطبقة 6: خادم لا يغلق الباب في وجهك

بجانب الطبقات: نسخة احتياطية تثبت أنها تُستعاد

البوابة أمام كل إصدار

هاجم نظامك بنفسك، على الورق

قائمة الفحص