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'

ಉದಾಹರಣೆಯಿಂದ ಸಂಪರ್ಕ ಯಶಸ್ವಿಯಾಗಿ ನಿಮ್ಮ ಮೇಜಿನಿಂದ ವಿಫಲವಾದರೆ, ಅನ್ವಯದ ಮಾರ್ಗ ಸರಿಯಾಗಿದೆ ಮತ್ತು ಸರಿಪಡಿಸಬೇಕಾದದ್ದು ನಿಮ್ಮ ಪ್ರವೇಶ. ಎರಡೂ ಕಡೆಯಿಂದ ವಿಫಲವಾದರೆ, ರುಜುವಾತುಗಳಿಂದಲ್ಲ, ಮೇಲಿನ ಗುಂಪು ಮತ್ತು ಮಾರ್ಗ ಪರಿಶೀಲನೆಗಳಿಂದ ಆರಂಭಿಸಿ. ಆ ಒಂದೇ ಹೋಲಿಕೆಯು ಈ ಟಿಕೆಟ್ಗಳು ಉಂಟುಮಾಡುವ ಬಹುಪಾಲು ಗೊಂದಲವನ್ನು ತಡೆಯುತ್ತದೆ.