EC2 ਤੋਂ ਨਿੱਜੀ RDS: ਉਹੀ VPC, peering ਜਾਂ ਕੁਝ ਹੋਰ?

ਡਿਵੈਲਪਰ ਦਾ ਲੈਪਟਾਪ ਸਟਾਫ਼ VPN ਰਾਹੀਂ ਨਿੱਜੀ RDS ਇੰਸਟੈਂਸ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ, ਪਰ EC2 ਉੱਤੇ ਐਪਲੀਕੇਸ਼ਨ ਬਿਲਕੁਲ ਵੀ ਕਨੈਕਟ ਨਹੀਂ ਹੋ ਸਕਦੀ। ਇਹ ਟੁੱਟੀ ਡਿਪਲਾਇਮੈਂਟ ਨਹੀਂ ਹੈ। ਲੈਪਟਾਪ ਵਿੱਚ ਇੱਕ ਟਨਲ ਹੈ ਜੋ EC2 ਇੰਸਟੈਂਸ ਕਦੇ ਵਿਰਾਸਤ ਵਿੱਚ ਨਹੀਂ ਲੈਂਦਾ, ਅਤੇ RDS ਵਿੱਚ «ਨਿੱਜੀ» ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਡੇਟਾਬੇਸ ਦਾ ਕੋਈ ਜਨਤਕ ਐਂਡਪੌਇੰਟ ਨਹੀਂ, ਇਹ ਨਹੀਂ ਕਿ ਮਨੁੱਖੀ VPN ਵਰਤੋਂਕਾਰ ਹੀ ਇੱਕੋ-ਇੱਕ ਮਨਜ਼ੂਰ ਕਾਲਰ ਹਨ। ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਆਪਣਾ ਅਧਿਕ੍ਰਿਤ ਮਾਰਗ, ਸੁਰੱਖਿਆ ਸਮੂਹ ਨਾਲ ਆਪਣਾ ਸੰਬੰਧ ਅਤੇ ਡੇਟਾਬੇਸ ਵਿੱਚ ਆਪਣੀ ਪਛਾਣ ਚਾਹੀਦੀ ਹੈ, ਅਤੇ ਇਹ ਤਿੰਨੇ ਚੁਣਨ ਦਾ ਕ੍ਰਮ ਡੀਬੱਗਿੰਗ ਦਾ ਵੱਡਾ ਹਿੱਸਾ ਬਚਾਉਂਦਾ ਹੈ। ਪਹਿਲਾਂ ਮਾਰਗ ਤੈਅ ਕਰੋ, ਫਿਰ ਇਜਾਜ਼ਤਾਂ, ਅਤੇ ਫਿਰ ਆਪਣੇ ਡੈਸਕ ਤੋਂ ਨਹੀਂ, ਡਿਪਲਾਇ ਕੀਤੇ ਵਾਤਾਵਰਣ ਤੋਂ ਪੁਸ਼ਟੀ ਕਰੋ।

ਲੈਪਟਾਪ ਦਾ VPN ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਮਾਰਗ ਨਹੀਂ ਹੈ

ਸਟਾਫ਼ VPN ਲੋਕਾਂ ਲਈ ਜੋ ਵੀ ਕਰੇ, ਇਹ ਕਿਸੇ ਇੰਸਟੈਂਸ ਲਈ ਕੁਝ ਨਹੀਂ ਕਰਦਾ, ਜਦੋਂ ਤੱਕ ਉਹ ਇੰਸਟੈਂਸ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਉਸੇ ਨੈੱਟਵਰਕ ਮਾਰਗ ਦਾ ਹਿੱਸਾ ਨਹੀਂ ਹੁੰਦਾ। ਨਿੱਜੀ ਸਬਨੈੱਟ ਵਿੱਚ EC2 ਇੰਸਟੈਂਸ VPC ਰਾਊਟਿੰਗ, ਸੁਰੱਖਿਆ ਸਮੂਹਾਂ ਅਤੇ ਨੈੱਟਵਰਕ ACL ਰਾਹੀਂ RDS ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ। ਇਹ ਮਨੁੱਖ ਦਾ ਟਨਲ, ਮਨੁੱਖ ਦਾ ਸੈਸ਼ਨ ਜਾਂ ਮਨੁੱਖ ਦੇ ਪ੍ਰਮਾਣ ਵਿਰਾਸਤ ਵਿੱਚ ਨਹੀਂ ਲੈਂਦਾ, ਅਤੇ ਨਹੀਂ ਲੈਣਾ ਚਾਹੀਦਾ: ਬਿਨਾਂ ਨਿਗਰਾਨੀ ਵਾਲੀ ਐਪਲੀਕੇਸ਼ਨ ਕਨੈਕਟੀਵਿਟੀ ਅਤੇ ਸਟਾਫ਼ ਦੀ ਦੂਰ-ਸਥਿਤ ਪਹੁੰਚ ਨੂੰ ਸੁਤੰਤਰ ਤੌਰ 'ਤੇ ਕੰਮ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।

ਇਹ ਸੁਤੰਤਰਤਾ ਇੱਕ ਲੱਛਣ ਹੈ। ਜਦੋਂ VPN ਡਾਊਨ ਹੁੰਦਾ ਹੈ, ਐਪਲੀਕੇਸ਼ਨ ਕੰਮ ਕਰਦੀ ਰਹਿੰਦੀ ਹੈ। ਜਦੋਂ ਐਪਲੀਕੇਸ਼ਨ ਗਲਤ ਵਿਵਹਾਰ ਕਰਦੀ ਹੈ, ਕਿਸੇ ਦੀ ਵੀ ਦੂਰ-ਸਥਿਤ ਪਹੁੰਚ ਨਹੀਂ ਜਾਂਦੀ। ਦੋਵਾਂ ਨੂੰ ਇੱਕ ਮਾਰਗ ਵਿੱਚ ਮਿਲਾਉਣ ਵਾਲੇ ਡਿਜ਼ਾਈਨ ਆਮ ਤੌਰ 'ਤੇ ਕਿਸੇ ਘਟਨਾ ਦੌਰਾਨ, ਸਭ ਤੋਂ ਮਾੜੇ ਪਲ 'ਤੇ ਪਤਾ ਲੱਗਦੇ ਹਨ।

ਫੈਸਲਾ 1: ਉਹੀ VPC, ਸਿੱਧਾ ਮਾਰਗ

ਜਦੋਂ ਐਪਲੀਕੇਸ਼ਨ ਅਤੇ ਡੇਟਾਬੇਸ ਇੱਕੋ VPC ਵਿੱਚ ਸਿੱਧੀ ਰਾਊਟਿੰਗ ਨਾਲ ਅਤੇ ਉਹਨਾਂ ਵਿਚਕਾਰ ਕੋਈ ਨਿਰੀਖਣ ਮੱਧਸਥ ਡਿਵਾਈਸ ਬਿਨਾਂ ਹੁੰਦੇ ਹਨ, ਮਾਰਗ ਸਧਾਰਨ ਹੁੰਦਾ ਹੈ ਅਤੇ ਸੁਰੱਖਿਆ ਸਮੂਹ ਸੰਦਰਭ ਉਪਲਬਧ ਸਭ ਤੋਂ ਸ਼ਕਤੀਸ਼ਾਲੀ ਸਾਧਨ ਹੈ। ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਇਸਦਾ ਆਪਣਾ ਸਮੂਹ ਦਿਓ, ਫਿਰ ਪਤਾ ਰੇਂਜ ਤੋਂ ਨਹੀਂ, ਉਸ ਸਮੂਹ ਤੋਂ ਡੇਟਾਬੇਸ ਪੋਰਟ ਦੀ ਇਜਾਜ਼ਤ ਦਿਓ:

aws ec2 authorize-security-group-ingress --group-id sg-0db123   --protocol tcp --port 5432 --source-group sg-0app456

aws rds describe-db-instances --db-instance-identifier prod-db   --query 'DBInstances[0].{Endpoint:Endpoint.Address,Port:Endpoint.Port,Public:PubliclyAccessible,Groups:VpcSecurityGroups}'

ਪੋਰਟ ਉਦਾਹਰਣ ਲਈ ਹੈ ਅਤੇ ਇੰਜਣ ਨਾਲ ਮੇਲ ਖਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਸਮੂਹ ਸੰਦਰਭ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਇੰਸਟੈਂਸਾਂ ਤੋਂ ਟ੍ਰੈਫਿਕ ਨੂੰ ਅਧਿਕ੍ਰਿਤ ਕਰਦਾ ਹੈ; ਇਹ ਉਹਨਾਂ ਦੇ ਨਿਯਮ ਕਾਪੀ ਨਹੀਂ ਕਰਦਾ ਅਤੇ ਡੇਟਾਬੇਸ ਲੌਗਇਨ ਨਹੀਂ ਬਣਾਉਂਦਾ। ਦੋ ਵੱਖਰੀਆਂ ਸਮੱਸਿਆਵਾਂ, ਦੋ ਵੱਖਰੇ ਹੱਲ।

ਫਿਰ ਹੁਣੇ ਜੋੜੇ ਨਿਯਮ 'ਤੇ ਰੁਕਣ ਦੀ ਬਜਾਏ ਮਾਰਗ ਦਾ ਬਾਕੀ ਹਿੱਸਾ ਜਾਂਚੋ। ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਆਊਟਬਾਊਂਡ ਨੀਤੀ, ਡੇਟਾਬੇਸ ਨਾਲ ਜੁੜੇ ਸਮੂਹਾਂ ਦਾ ਪੂਰਾ ਸੈੱਟ, ਸਬਨੈੱਟ ਰਾਊਟ ਟੇਬਲ ਅਤੇ ਕੋਈ ਵੀ ਨੈੱਟਵਰਕ ACL—ਸਭ ਨੂੰ ਮੇਲ ਖਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਸੁਰੱਖਿਆ ਸਮੂਹ ਦੇ ਨਿਯਮ ਸਟੇਟਫੁਲ ਹੁੰਦੇ ਹਨ, ਜਦੋਂ ਕਿ ਕਸਟਮ ਨੈੱਟਵਰਕ ACL ਨੂੰ ਬੇਨਤੀ ਅਤੇ ਵਾਪਸੀ ਟ੍ਰੈਫਿਕ ਨੂੰ ਵੱਖਰੇ ਨਿਯਮਾਂ ਵਿੱਚ ਇਜਾਜ਼ਤ ਦੇਣੀ ਚਾਹੀਦੀ ਹੈ, ਅਸਥਾਈ ਪੋਰਟਾਂ ਸਮੇਤ। ਨਵਾਂ ਤੰਗ ਡੇਟਾਬੇਸ ਨਿਯਮ ਪਹਿਲਾਂ ਜੁੜੀ ਪੁਰਾਣੀ ਚੌੜੀ ਇਜਾਜ਼ਤ ਨੂੰ ਵੀ ਰੱਦ ਨਹੀਂ ਕਰਦਾ।

ਫੈਸਲਾ 2: ਦੂਜਾ VPC ਜਾਂ ਦੂਜਾ ਖਾਤਾ

ਜੇ ਐਪਲੀਕੇਸ਼ਨ ਦੂਜੇ VPC ਵਿੱਚ ਹੈ, ਤਾਂ ਨੈੱਟਵਰਕ ਦੇ ਮਾਲਕ ਸਮਰਥਿਤ ਨਿੱਜੀ ਇੰਟਰਕਨੈਕਟ ਚੁਣਦੇ ਹਨ: peering, ਟ੍ਰਾਂਜ਼ਿਟ ਡਿਜ਼ਾਈਨ ਜਾਂ ਸਾਂਝੀ VPC ਵਿਵਸਥਾ। ਫਿਰ ਰਾਊਟਿੰਗ ਦੀਆਂ ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ, ਨਾਮ ਹੱਲ RDS ਐਂਡਪੌਇੰਟ ਲਈ ਕੰਮ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਡੇਟਾਬੇਸ ਨੀਤੀ ਜਿਸ ਸਰੋਤ ਦਾ ਮੁਲਾਂਕਣ ਕਰਦੀ ਹੈ ਉਹ ਅਸਲ ਵਿੱਚ ਆਉਣ ਵਾਲੇ ਨਾਲ ਮੇਲ ਖਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਖਾਤਾ ਨਾਮ ਮੇਲ ਖਾਣਾ ਜਾਂ ਸਾਂਝਾ ਬਿਲਿੰਗ ਸੰਬੰਧ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੁਝ ਨਹੀਂ ਦਿੰਦਾ।

ਸੁਰੱਖਿਆ ਸਮੂਹ ਸੰਦਰਭ ਉਹ ਹਿੱਸਾ ਹੈ ਜੋ ਬਦਲਦਾ ਹੈ। ਇਹ ਕਈ ਨਿੱਜੀ ਇੰਟਰਕਨੈਕਟ ਡਿਜ਼ਾਈਨਾਂ ਵਿੱਚ ਕੰਮ ਕਰਦਾ ਹੈ, ਪਰ ਜਿਸ ਪਲ ਕੋਈ ਮੱਧਸਥ ਡਿਵਾਈਸ ਸਰੋਤ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਦੀ ਹੈ ਜਾਂ ਕਨੈਕਸ਼ਨ ਖਤਮ ਕਰਦੀ ਹੈ, ਉਸੇ ਪਲ ਕੰਮ ਕਰਨਾ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ, ਕਿਉਂਕਿ ਫਿਰ ਡੇਟਾਬੇਸ ਤੁਹਾਡੇ ਐਪਲੀਕੇਸ਼ਨ ਸਮੂਹ ਦੀ ਬਜਾਏ ਮੱਧਸਥ ਡਿਵਾਈਸ ਦੇਖਦਾ ਹੈ। RDS VPC ਦ੍ਰਿਸ਼ ਇੱਕੋ VPC ਦੇ ਅੰਦਰ ਪਹੁੰਚ ਨੂੰ ਦੂਜੀਆਂ ਵਿਵਸਥਾਵਾਂ ਤੋਂ ਵੱਖ ਕਰਦੇ ਹਨ, ਅਤੇ ਇਹ ਮੰਨਣ ਤੋਂ ਪਹਿਲਾਂ ਕਿ ਨਿਯਮ ਦੀ ਸ਼ੈਲੀ ਅੱਗੇ ਵਧਦੀ ਹੈ, ਆਪਣੀ ਖਾਸ ਟੋਪੋਲੋਜੀ ਨੂੰ ਉਹਨਾਂ ਨਾਲ ਜਾਂਚਣਾ ਸਹੀ ਹੈ।

ਗੁੰਮ ਮਾਰਗ ਨੂੰ ਡੇਟਾਬੇਸ ਨੂੰ ਜਨਤਕ ਤੌਰ 'ਤੇ ਪਹੁੰਚਯੋਗ ਬਣਾ ਕੇ ਹੱਲ ਨਾ ਕਰੋ। ਉਹ ਵੱਖਰੇ ਮਾਲਕ ਵਾਲਾ ਵੱਖਰਾ ਐਕਸਪੋਜ਼ਰ ਫੈਸਲਾ ਹੈ, ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਉਹ ਵਿਅਕਤੀ ਸੁਝਾਅ ਦਿੰਦਾ ਹੈ ਜੋ ਨਤੀਜੇ ਤੋਂ ਸਭ ਤੋਂ ਦੂਰ ਹੈ।

ਫੈਸਲਾ 3: ਡੇਟਾਬੇਸ ਕਿਹੜੀ ਪਛਾਣ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ

ਨੈੱਟਵਰਕ ਪਹੁੰਚ ਅਤੇ ਡੇਟਾਬੇਸ ਪ੍ਰਮਾਣੀਕਰਨ ਵੱਖਰੀਆਂ ਪਰਤਾਂ ਹਨ, ਅਤੇ ਇਹਨਾਂ ਨੂੰ ਮਿਲਾਉਣ ਨਾਲ ਸਭ ਤੋਂ ਭੁਲਾਉਣ ਵਾਲੀਆਂ ਗਲਤੀਆਂ ਬਣਦੀਆਂ ਹਨ। ਇੰਸਟੈਂਸ ਭੂਮਿਕਾ AWS API ਕਾਲ ਕਰਨ ਲਈ AWS ਪਛਾਣ ਹੈ। ਇਹ ਡੇਟਾਬੇਸ ਵਰਤੋਂਕਾਰ ਨਹੀਂ ਹੈ। IAM ਡੇਟਾਬੇਸ ਪ੍ਰਮਾਣੀਕਰਨ ਇੱਕ ਸਮਰਥਿਤ ਵਿਸ਼ੇਸ਼ਤਾ ਹੈ ਜਿੱਥੇ ਇੰਜਣ ਅਤੇ ਸੰਰਚਨਾ ਇਜਾਜ਼ਤ ਦਿੰਦੇ ਹਨ, ਅਤੇ ਇਹ ਅਜੇ ਵੀ ਡੇਟਾਬੇਸ ਵਰਤੋਂਕਾਰ ਵਿੱਚ ਮੈਪਿੰਗ ਹੈ, ਇਸਦਾ ਬਦਲ ਨਹੀਂ।

ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਸੰਰਚਨਾ ਵਿੱਚ ਇੱਕ ਖੋਜ ਤੋਂ ਫੜੇ ਪਤੇ ਦੀ ਬਜਾਏ RDS ਐਂਡਪੌਇੰਟ ਦਾ ਨਾਮ ਵਰਤੋ। Multi-AZ ਫੇਲਓਵਰ ਉਸ ਨਾਮ ਪਿੱਛੇ ਦਾ ਪਤਾ ਬਦਲਦਾ ਹੈ, ਅਤੇ IP 'ਤੇ ਪਿੰਨ ਕੀਤੀ ਐਪਲੀਕੇਸ਼ਨ ਠੀਕ ਉਸੇ ਪਲ ਫੇਲ ਹੋਵੇਗੀ ਜਦੋਂ ਇਸਦੀ ਸਭ ਤੋਂ ਵੱਧ ਲੋੜ ਹੋਵੇ। ਗਲਤੀ ਗਾਇਬ ਕਰਨ ਲਈ ਇੰਜਣ ਦੀ TLS ਜਾਂਚ ਬੰਦ ਕਰਨ ਦੀ ਬਜਾਏ ਚਾਲੂ ਰੱਖੋ, ਕਿਉਂਕਿ ਜਾਂਚ ਫੇਲ ਹੋਣਾ ਤੁਹਾਨੂੰ ਉਸ ਐਂਡਪੌਇੰਟ ਬਾਰੇ ਕੁਝ ਦੱਸਦਾ ਹੈ ਜਿੱਥੇ ਤੁਸੀਂ ਪਹੁੰਚੇ।

ਫਿਰ ਡੇਟਾਬੇਸ ਖਾਤੇ ਨੂੰ ਉਹ ਘੱਟੋ-ਘੱਟ ਦਿਓ ਜੋ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਚਾਹੀਦਾ ਹੈ, ਉਸ ਸਕੀਮਾ ਵਿੱਚ ਜੋ ਇਹ ਅਸਲ ਵਿੱਚ ਵਰਤਦੀ ਹੈ। ਉਹ ਕੰਮ ਉਬਾਊ ਹੈ, ਇਹ ਆਡਿਟਯੋਗ ਹੈ, ਅਤੇ ਘਟਨਾ ਸਮੀਖਿਆ ਉਸੇ ਹਿੱਸੇ ਬਾਰੇ ਪੁੱਛੇਗੀ।

ਡਿਪਲਾਇ ਕੀਤੇ ਵਾਤਾਵਰਣ ਤੋਂ ਪੁਸ਼ਟੀ ਕਰੋ

ਇੰਸਟੈਂਸ ਤੋਂ ਜਾਂ ਉਸੇ ਸਮੂਹ, ਸਬਨੈੱਟ ਅਤੇ ਭੂਮਿਕਾ ਨਾਲ ਚੱਲਣ ਵਾਲੇ ਕੰਮ ਤੋਂ ਟੈਸਟ ਕਰੋ। ਚਾਰ ਫੇਲ੍ਹਤਾਂ ਲੈਪਟਾਪ ਤੋਂ ਇੱਕੋ ਜਿਹੀਆਂ ਦਿਸਦੀਆਂ ਹਨ ਅਤੇ ਉੱਥੋਂ ਆਸਾਨੀ ਨਾਲ ਵੱਖ ਕੀਤੀਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ: ਹੱਲ ਨਾ ਹੋਣ ਵਾਲਾ ਨਾਮ, ਸਮਾਂ ਖਤਮ ਹੋਣ ਵਾਲਾ ਕਨੈਕਸ਼ਨ, TLS ਪ੍ਰਮਾਣਿਕਤਾ ਫੇਲ੍ਹਤਾ ਅਤੇ ਰੱਦ ਕੀਤਾ ਡੇਟਾਬੇਸ ਲੌਗਇਨ। ਹਰ ਇੱਕ ਵੱਖਰੀ ਸੀਮਾ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੀ ਹੈ, ਅਤੇ ਇਹ ਜਾਣਨ ਤੋਂ ਪਹਿਲਾਂ ਕਿ ਤੁਹਾਡੇ ਕੋਲ ਕਿਹੜੀ ਹੈ, ਡੇਟਾਬੇਸ ਦਾ ਐਕਸਪੋਜ਼ਰ ਬਦਲਣਾ ਅਨੁਮਾਨ ਹੈ।

psql "host=prod-db.abc123.eu-west-1.rds.amazonaws.com port=5432 dbname=app sslmode=verify-full" -c 'select 1'

ਜੇ ਇੰਸਟੈਂਸ ਤੋਂ ਕਨੈਕਸ਼ਨ ਸਫਲ ਹੋਵੇ ਅਤੇ ਤੁਹਾਡੇ ਡੈਸਕ ਤੋਂ ਫੇਲ ਹੋਵੇ, ਤਾਂ ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਮਾਰਗ ਠੀਕ ਹੈ ਅਤੇ ਤੁਹਾਡੀ ਪਹੁੰਚ ਸੁਧਾਰਨ ਵਾਲੀ ਹੈ। ਜੇ ਦੋਵਾਂ ਥਾਵਾਂ ਤੋਂ ਫੇਲ ਹੋਵੇ, ਤਾਂ ਪ੍ਰਮਾਣਾਂ ਤੋਂ ਨਹੀਂ, ਉੱਪਰ ਦਿੱਤੀਆਂ ਸਮੂਹ ਅਤੇ ਮਾਰਗ ਜਾਂਚਾਂ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ। ਇਹੀ ਇੱਕ ਤੁਲਨਾ ਇਹਨਾਂ ਟਿਕਟਾਂ ਕਾਰਨ ਹੋਣ ਵਾਲੀ ਬਹੁਤੀ ਖਿੱਚੋਤਾਣ ਰੋਕਦੀ ਹੈ।