MySQL ਵਿੱਚ ਐਨਕ੍ਰਿਪਸ਼ਨ: ਕੀਸਟੋਰ

ਕੋਰਸ ਲਈ ਨਵੇਂ ਦਾਖਲੇ ਦੀ ਸ਼ੁਰੂਆਤ ਦੀ ਉਮੀਦ ਵਿੱਚ "ਡਾਟਾਬੇਸ" ਅਸੀਂ ਤੁਹਾਡੇ ਲਈ ਇੱਕ ਉਪਯੋਗੀ ਲੇਖ ਦਾ ਅਨੁਵਾਦ ਤਿਆਰ ਕੀਤਾ ਹੈ।

ਪਾਰਦਰਸ਼ੀ ਡੇਟਾ ਐਨਕ੍ਰਿਪਸ਼ਨ (TDE) ਵਿੱਚ ਪ੍ਰਗਟ ਹੋਇਆ MySQL ਲਈ ਪਰਕੋਨਾ ਸਰਵਰ ਅਤੇ ਕੁਝ ਸਮੇਂ ਲਈ MySQL. ਪਰ ਕੀ ਤੁਸੀਂ ਕਦੇ ਇਸ ਬਾਰੇ ਸੋਚਿਆ ਹੈ ਕਿ ਇਹ ਹੁੱਡ ਦੇ ਹੇਠਾਂ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ ਤੁਹਾਡੇ ਸਰਵਰ 'ਤੇ TDE ਦਾ ਕੀ ਪ੍ਰਭਾਵ ਹੋ ਸਕਦਾ ਹੈ? ਲੇਖਾਂ ਦੀ ਇਸ ਲੜੀ ਵਿੱਚ ਅਸੀਂ ਦੇਖਾਂਗੇ ਕਿ TDE ਅੰਦਰੂਨੀ ਤੌਰ 'ਤੇ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ। ਆਓ ਕੁੰਜੀ ਸਟੋਰੇਜ ਨਾਲ ਸ਼ੁਰੂ ਕਰੀਏ, ਕਿਉਂਕਿ ਕਿਸੇ ਵੀ ਏਨਕ੍ਰਿਪਸ਼ਨ ਦੇ ਕੰਮ ਕਰਨ ਲਈ ਇਹ ਲੋੜੀਂਦਾ ਹੈ। ਫਿਰ ਅਸੀਂ ਇਸ ਗੱਲ 'ਤੇ ਡੂੰਘਾਈ ਨਾਲ ਵਿਚਾਰ ਕਰਾਂਗੇ ਕਿ MySQL/MySQL ਲਈ ਪਰਕੋਨਾ ਸਰਵਰ ਵਿੱਚ ਐਨਕ੍ਰਿਪਸ਼ਨ ਕਿਵੇਂ ਕੰਮ ਕਰਦੀ ਹੈ ਅਤੇ MySQL ਲਈ ਪਰਕੋਨਾ ਸਰਵਰ ਵਿੱਚ ਕਿਹੜੀਆਂ ਵਾਧੂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਹਨ।

MySQL ਕੀਰਿੰਗ

ਕੀਰਿੰਗ ਉਹ ਪਲੱਗਇਨ ਹਨ ਜੋ ਸਰਵਰ ਨੂੰ ਇੱਕ ਸਥਾਨਕ ਫਾਈਲ (ਕੀਰਿੰਗ_ਫਾਈਲ) ਜਾਂ ਰਿਮੋਟ ਸਰਵਰ (ਜਿਵੇਂ ਕਿ ਹੈਸ਼ੀਕੌਰਪ ਵਾਲਟ) ਵਿੱਚ ਕੁੰਜੀਆਂ ਦੀ ਪੁੱਛਗਿੱਛ ਕਰਨ, ਬਣਾਉਣ ਅਤੇ ਮਿਟਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੇ ਹਨ। ਕੁੰਜੀਆਂ ਨੂੰ ਉਹਨਾਂ ਦੀ ਮੁੜ ਪ੍ਰਾਪਤੀ ਨੂੰ ਤੇਜ਼ ਕਰਨ ਲਈ ਹਮੇਸ਼ਾਂ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਕੈਸ਼ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

ਪਲੱਗਇਨ ਨੂੰ ਦੋ ਸ਼੍ਰੇਣੀਆਂ ਵਿੱਚ ਵੰਡਿਆ ਜਾ ਸਕਦਾ ਹੈ:

• ਸਥਾਨਕ ਸਟੋਰੇਜ। ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਸਥਾਨਕ ਫਾਈਲ (ਅਸੀਂ ਇਸਨੂੰ ਇੱਕ ਫਾਈਲ-ਅਧਾਰਿਤ ਕੀਰਿੰਗ ਕਹਿੰਦੇ ਹਾਂ)।
• ਰਿਮੋਟ ਸਟੋਰੇਜ। ਉਦਾਹਰਨ ਲਈ, ਵਾਲਟ ਸਰਵਰ (ਅਸੀਂ ਇਸਨੂੰ ਸਰਵਰ-ਅਧਾਰਿਤ ਕੀਰਿੰਗ ਕਹਿੰਦੇ ਹਾਂ)।

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

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

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

ਮੁੱਖ ਜਾਣਕਾਰੀ ਵਿੱਚ ਹੇਠ ਲਿਖੇ ਸ਼ਾਮਲ ਹਨ:

• ਕੁੰਜੀ ਆਈ.ਡੀ — ਕੁੰਜੀ ਪਛਾਣਕਰਤਾ, ਉਦਾਹਰਨ ਲਈ:
  INNODBKey-764d382a-7324-11e9-ad8f-9cb6d0d5dc99-1
• ਕੁੰਜੀ ਕਿਸਮ — ਵਰਤੇ ਗਏ ਐਨਕ੍ਰਿਪਸ਼ਨ ਐਲਗੋਰਿਦਮ 'ਤੇ ਆਧਾਰਿਤ ਮੁੱਖ ਕਿਸਮ, ਸੰਭਵ ਮੁੱਲ: “AES”, “RSA” ਜਾਂ “DSA”।
• ਕੁੰਜੀ ਲੰਬਾਈ — ਬਾਈਟਾਂ ਵਿੱਚ ਮੁੱਖ ਲੰਬਾਈ, AES: 16, 24 ਜਾਂ 32, RSA 128, 256, 512 ਅਤੇ DSA 128, 256 ਜਾਂ 384।
• ਉਪਭੋਗੀ ਨੂੰ - ਕੁੰਜੀ ਦਾ ਮਾਲਕ। ਜੇਕਰ ਕੁੰਜੀ ਸਿਸਟਮ ਹੈ, ਉਦਾਹਰਨ ਲਈ, ਮਾਸਟਰ ਕੁੰਜੀ, ਤਾਂ ਇਹ ਖੇਤਰ ਖਾਲੀ ਹੈ। ਜੇਕਰ keyring_udf ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਕੁੰਜੀ ਬਣਾਈ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਇਹ ਖੇਤਰ ਕੁੰਜੀ ਦੇ ਮਾਲਕ ਦੀ ਪਛਾਣ ਕਰਦਾ ਹੈ।
• ਕੁੰਜੀ ਆਪਣੇ ਆਪ ਨੂੰ

ਕੁੰਜੀ ਨੂੰ ਜੋੜੇ ਦੁਆਰਾ ਵਿਲੱਖਣ ਤੌਰ 'ਤੇ ਪਛਾਣਿਆ ਜਾਂਦਾ ਹੈ: key_id, ਉਪਭੋਗਤਾ।

ਕੁੰਜੀਆਂ ਨੂੰ ਸਟੋਰ ਕਰਨ ਅਤੇ ਮਿਟਾਉਣ ਵਿੱਚ ਵੀ ਅੰਤਰ ਹਨ।

ਫਾਈਲ ਸਟੋਰੇਜ ਤੇਜ਼ ਹੈ। ਤੁਸੀਂ ਸੋਚ ਸਕਦੇ ਹੋ ਕਿ ਇੱਕ ਕੁੰਜੀ ਸਟੋਰ ਸਿਰਫ਼ ਇੱਕ ਵਾਰ ਇੱਕ ਫਾਈਲ ਦੀ ਕੁੰਜੀ ਲਿਖ ਰਿਹਾ ਹੈ, ਪਰ ਨਹੀਂ, ਇੱਥੇ ਹੋਰ ਵੀ ਚੱਲ ਰਿਹਾ ਹੈ। ਜਦੋਂ ਵੀ ਕੋਈ ਫਾਈਲ ਸਟੋਰੇਜ ਸੋਧ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਸਾਰੀ ਸਮੱਗਰੀ ਦੀ ਬੈਕਅੱਪ ਕਾਪੀ ਬਣਾਈ ਜਾਂਦੀ ਹੈ। ਮੰਨ ਲਓ ਕਿ ਫਾਈਲ ਨੂੰ my_biggest_secrets ਕਿਹਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਬੈਕਅੱਪ ਕਾਪੀ my_biggest_secrets.backup ਹੋਵੇਗੀ। ਅੱਗੇ, ਕੈਸ਼ ਬਦਲਿਆ ਜਾਂਦਾ ਹੈ (ਕੁੰਜੀਆਂ ਜੋੜੀਆਂ ਜਾਂ ਮਿਟਾਈਆਂ ਜਾਂਦੀਆਂ ਹਨ) ਅਤੇ, ਜੇ ਸਭ ਕੁਝ ਸਫਲ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਕੈਸ਼ ਨੂੰ ਇੱਕ ਫਾਈਲ ਵਿੱਚ ਰੀਸੈਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਬਹੁਤ ਘੱਟ ਮਾਮਲਿਆਂ ਵਿੱਚ, ਜਿਵੇਂ ਕਿ ਸਰਵਰ ਅਸਫਲਤਾ, ਤੁਸੀਂ ਇਹ ਬੈਕਅੱਪ ਫਾਈਲ ਦੇਖ ਸਕਦੇ ਹੋ। ਅਗਲੀ ਵਾਰ ਕੁੰਜੀਆਂ ਲੋਡ ਹੋਣ 'ਤੇ ਬੈਕਅੱਪ ਫਾਈਲ ਮਿਟਾ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ (ਆਮ ਤੌਰ 'ਤੇ ਸਰਵਰ ਦੇ ਮੁੜ ਚਾਲੂ ਹੋਣ ਤੋਂ ਬਾਅਦ)।

ਸਰਵਰ ਸਟੋਰੇਜ ਵਿੱਚ ਇੱਕ ਕੁੰਜੀ ਨੂੰ ਸੁਰੱਖਿਅਤ ਜਾਂ ਮਿਟਾਉਣ ਵੇਲੇ, ਸਟੋਰੇਜ ਨੂੰ "ਕੁੰਜੀ ਭੇਜੋ" / "ਕੁੰਜੀ ਨੂੰ ਮਿਟਾਉਣ ਦੀ ਬੇਨਤੀ" ਕਮਾਂਡਾਂ ਨਾਲ MySQL ਸਰਵਰ ਨਾਲ ਜੁੜਨਾ ਚਾਹੀਦਾ ਹੈ।

ਚਲੋ ਸਰਵਰ ਸਟਾਰਟਅਪ ਸਪੀਡ 'ਤੇ ਵਾਪਸ ਆਓ। ਇਸ ਤੱਥ ਤੋਂ ਇਲਾਵਾ ਕਿ ਲਾਂਚ ਦੀ ਗਤੀ ਵਾਲਟ ਦੁਆਰਾ ਹੀ ਪ੍ਰਭਾਵਿਤ ਹੁੰਦੀ ਹੈ, ਇਹ ਵੀ ਮੁੱਦਾ ਹੈ ਕਿ ਸ਼ੁਰੂਆਤ 'ਤੇ ਵਾਲਟ ਤੋਂ ਕਿੰਨੀਆਂ ਕੁੰਜੀਆਂ ਪ੍ਰਾਪਤ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਬੇਸ਼ੱਕ, ਇਹ ਸਰਵਰ ਸਟੋਰੇਜ ਲਈ ਖਾਸ ਤੌਰ 'ਤੇ ਮਹੱਤਵਪੂਰਨ ਹੈ. ਸ਼ੁਰੂਆਤੀ ਸਮੇਂ, ਸਰਵਰ ਜਾਂਚ ਕਰਦਾ ਹੈ ਕਿ ਐਨਕ੍ਰਿਪਟਡ ਟੇਬਲ/ਟੇਬਲਸਪੇਸ ਲਈ ਕਿਹੜੀ ਕੁੰਜੀ ਦੀ ਲੋੜ ਹੈ ਅਤੇ ਸਟੋਰੇਜ ਤੋਂ ਕੁੰਜੀ ਦੀ ਬੇਨਤੀ ਕਰਦਾ ਹੈ। ਮਾਸਟਰ ਕੁੰਜੀ ਇਨਕ੍ਰਿਪਸ਼ਨ ਵਾਲੇ "ਕਲੀਨ" ਸਰਵਰ 'ਤੇ, ਇੱਕ ਮਾਸਟਰ ਕੁੰਜੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ, ਜੋ ਸਟੋਰੇਜ ਤੋਂ ਪ੍ਰਾਪਤ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ। ਹਾਲਾਂਕਿ, ਵੱਡੀ ਗਿਣਤੀ ਵਿੱਚ ਕੁੰਜੀਆਂ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ, ਉਦਾਹਰਨ ਲਈ, ਜਦੋਂ ਬੈਕਅੱਪ ਸਰਵਰ ਪ੍ਰਾਇਮਰੀ ਸਰਵਰ ਤੋਂ ਬੈਕਅੱਪ ਨੂੰ ਬਹਾਲ ਕਰ ਰਿਹਾ ਹੈ। ਅਜਿਹੇ ਮਾਮਲਿਆਂ ਵਿੱਚ, ਮਾਸਟਰ ਕੁੰਜੀ ਨੂੰ ਰੋਟੇਸ਼ਨ ਪ੍ਰਦਾਨ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਇਸ ਨੂੰ ਭਵਿੱਖ ਦੇ ਲੇਖਾਂ ਵਿੱਚ ਵਧੇਰੇ ਵਿਸਤਾਰ ਵਿੱਚ ਕਵਰ ਕੀਤਾ ਜਾਵੇਗਾ, ਹਾਲਾਂਕਿ ਇੱਥੇ ਮੈਂ ਇਹ ਨੋਟ ਕਰਨਾ ਚਾਹਾਂਗਾ ਕਿ ਇੱਕ ਸਰਵਰ ਮਲਟੀਪਲ ਮਾਸਟਰ ਕੁੰਜੀਆਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਸ਼ੁਰੂ ਹੋਣ ਵਿੱਚ ਥੋੜਾ ਸਮਾਂ ਲੈ ਸਕਦਾ ਹੈ, ਖਾਸ ਕਰਕੇ ਜਦੋਂ ਸਰਵਰ-ਸਾਈਡ ਕੁੰਜੀ ਸਟੋਰ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ।

ਹੁਣ ਕੀਰਿੰਗ_ਫਾਇਲ ਬਾਰੇ ਥੋੜੀ ਹੋਰ ਗੱਲ ਕਰੀਏ। ਜਦੋਂ ਮੈਂ ਕੀਰਿੰਗ_ਫਾਈਲ ਦਾ ਵਿਕਾਸ ਕਰ ਰਿਹਾ ਸੀ, ਤਾਂ ਮੈਂ ਇਸ ਬਾਰੇ ਵੀ ਚਿੰਤਤ ਸੀ ਕਿ ਸਰਵਰ ਦੇ ਚੱਲਣ ਦੌਰਾਨ ਕੀਰਿੰਗ_ਫਾਈਲ ਤਬਦੀਲੀਆਂ ਦੀ ਜਾਂਚ ਕਿਵੇਂ ਕਰਨੀ ਹੈ। 5.7 ਵਿੱਚ, ਜਾਂਚ ਫਾਈਲ ਅੰਕੜਿਆਂ ਦੇ ਅਧਾਰ ਤੇ ਕੀਤੀ ਗਈ ਸੀ, ਜੋ ਕਿ ਇੱਕ ਆਦਰਸ਼ ਹੱਲ ਨਹੀਂ ਸੀ, ਅਤੇ 8.0 ਵਿੱਚ ਇਸਨੂੰ ਇੱਕ SHA256 ਚੈੱਕਸਮ ਨਾਲ ਬਦਲ ਦਿੱਤਾ ਗਿਆ ਸੀ।

ਪਹਿਲੀ ਵਾਰ ਜਦੋਂ ਤੁਸੀਂ keyring_file ਚਲਾਉਂਦੇ ਹੋ, ਤਾਂ ਫਾਈਲ ਦੇ ਅੰਕੜੇ ਅਤੇ ਇੱਕ ਚੈਕਸਮ ਦੀ ਗਣਨਾ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਜੋ ਸਰਵਰ ਦੁਆਰਾ ਯਾਦ ਰੱਖੀ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਤਬਦੀਲੀਆਂ ਤਾਂ ਹੀ ਲਾਗੂ ਹੁੰਦੀਆਂ ਹਨ ਜੇਕਰ ਉਹ ਮੇਲ ਖਾਂਦੇ ਹਨ। ਜਦੋਂ ਫਾਈਲ ਬਦਲ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਚੈਕਸਮ ਅੱਪਡੇਟ ਹੋ ਜਾਂਦਾ ਹੈ।

ਅਸੀਂ ਪਹਿਲਾਂ ਹੀ ਮੁੱਖ ਵਾਲਟਸ ਬਾਰੇ ਬਹੁਤ ਸਾਰੇ ਸਵਾਲਾਂ ਨੂੰ ਕਵਰ ਕਰ ਚੁੱਕੇ ਹਾਂ। ਹਾਲਾਂਕਿ, ਇੱਕ ਹੋਰ ਮਹੱਤਵਪੂਰਨ ਵਿਸ਼ਾ ਹੈ ਜੋ ਅਕਸਰ ਭੁੱਲ ਜਾਂਦਾ ਹੈ ਜਾਂ ਗਲਤ ਸਮਝਿਆ ਜਾਂਦਾ ਹੈ: ਸਰਵਰਾਂ ਵਿੱਚ ਕੁੰਜੀਆਂ ਸਾਂਝੀਆਂ ਕਰਨਾ।

ਮੇਰਾ ਕੀ ਮਤਲਬ ਹੈ? ਕਲੱਸਟਰ ਵਿੱਚ ਹਰੇਕ ਸਰਵਰ (ਉਦਾਹਰਨ ਲਈ, ਪਰਕੋਨਾ ਸਰਵਰ) ਦਾ ਵਾਲਟ ਸਰਵਰ ਉੱਤੇ ਇੱਕ ਵੱਖਰਾ ਟਿਕਾਣਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਪਰਕੋਨਾ ਸਰਵਰ ਨੂੰ ਆਪਣੀਆਂ ਕੁੰਜੀਆਂ ਸਟੋਰ ਕਰਨੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ। ਸਟੋਰੇਜ਼ ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਕੀਤੀ ਹਰੇਕ ਮਾਸਟਰ ਕੁੰਜੀ ਵਿੱਚ ਇਸਦੇ ਪਛਾਣਕਰਤਾ ਦੇ ਅੰਦਰ ਪਰਕੋਨਾ ਸਰਵਰ ਦਾ GUID ਹੁੰਦਾ ਹੈ। ਇਹ ਮਹੱਤਵਪੂਰਨ ਕਿਉਂ ਹੈ? ਕਲਪਨਾ ਕਰੋ ਕਿ ਤੁਹਾਡੇ ਕੋਲ ਸਿਰਫ਼ ਇੱਕ ਵਾਲਟ ਸਰਵਰ ਹੈ ਅਤੇ ਕਲੱਸਟਰ ਵਿੱਚ ਸਾਰੇ ਪਰਕੋਨਾ ਸਰਵਰ ਉਸ ਸਿੰਗਲ ਵਾਲਟ ਸਰਵਰ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ। ਸਮੱਸਿਆ ਸਪੱਸ਼ਟ ਜਾਪਦੀ ਹੈ. ਜੇਕਰ ਸਾਰੇ ਪਰਕੋਨਾ ਸਰਵਰ ਵਿਲੱਖਣ ਪਛਾਣਕਰਤਾਵਾਂ ਤੋਂ ਬਿਨਾਂ ਇੱਕ ਮਾਸਟਰ ਕੁੰਜੀ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ, ਜਿਵੇਂ ਕਿ id = 1, id = 2, ਆਦਿ, ਤਾਂ ਕਲੱਸਟਰ ਵਿੱਚ ਸਾਰੇ ਸਰਵਰ ਇੱਕੋ ਮਾਸਟਰ ਕੁੰਜੀ ਦੀ ਵਰਤੋਂ ਕਰਨਗੇ। ਜੋ GUID ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ ਉਹ ਸਰਵਰਾਂ ਵਿਚਕਾਰ ਅੰਤਰ ਹੈ। ਜੇਕਰ ਇੱਕ ਵਿਲੱਖਣ GUID ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ ਹੈ ਤਾਂ ਸਰਵਰਾਂ ਵਿਚਕਾਰ ਕੁੰਜੀਆਂ ਨੂੰ ਸਾਂਝਾ ਕਰਨ ਬਾਰੇ ਕਿਉਂ ਗੱਲ ਕਰੋ? ਇੱਕ ਹੋਰ ਪਲੱਗਇਨ ਹੈ - keyring_udf. ਇਸ ਪਲੱਗਇਨ ਨਾਲ, ਤੁਹਾਡਾ ਸਰਵਰ ਉਪਭੋਗਤਾ ਆਪਣੀਆਂ ਕੁੰਜੀਆਂ ਨੂੰ ਵਾਲਟ ਸਰਵਰ 'ਤੇ ਸਟੋਰ ਕਰ ਸਕਦਾ ਹੈ। ਸਮੱਸਿਆ ਉਦੋਂ ਆਉਂਦੀ ਹੈ ਜਦੋਂ ਇੱਕ ਉਪਭੋਗਤਾ ਸਰਵਰ 1 ਤੇ ਇੱਕ ਕੁੰਜੀ ਬਣਾਉਂਦਾ ਹੈ, ਉਦਾਹਰਨ ਲਈ, ਅਤੇ ਫਿਰ ਸਰਵਰ 2 ਤੇ ਉਸੇ ID ਨਾਲ ਇੱਕ ਕੁੰਜੀ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ, ਉਦਾਹਰਨ ਲਈ:

--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
--1 значит успешное завершение
--server2:
select keyring_key_store('ROB_1','AES',"543210987654321");
1

ਉਡੀਕ ਕਰੋ। ਦੋਵੇਂ ਸਰਵਰ ਇੱਕੋ ਵਾਲਟ ਸਰਵਰ ਦੀ ਵਰਤੋਂ ਕਰ ਰਹੇ ਹਨ, ਕੀ ਸਰਵਰ2 'ਤੇ ਕੀਰਿੰਗ_ਕੀ_ਸਟੋਰ ਫੰਕਸ਼ਨ ਫੇਲ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ? ਦਿਲਚਸਪ ਗੱਲ ਇਹ ਹੈ ਕਿ, ਜੇਕਰ ਤੁਸੀਂ ਇੱਕ ਸਰਵਰ 'ਤੇ ਅਜਿਹਾ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਇੱਕ ਗਲਤੀ ਮਿਲੇਗੀ:

--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
select keyring_key_store('ROB_1','AES',"543210987654321");
0

ਇਹ ਸਹੀ ਹੈ, ROB_1 ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ ਹੈ।

ਆਓ ਪਹਿਲਾਂ ਦੂਜੀ ਉਦਾਹਰਣ ਦੀ ਚਰਚਾ ਕਰੀਏ। ਜਿਵੇਂ ਕਿ ਅਸੀਂ ਪਹਿਲਾਂ ਕਿਹਾ ਸੀ, ਕੀਰਿੰਗ_ਵਾਲਟ ਜਾਂ ਕੋਈ ਹੋਰ ਕੀਰਿੰਗ ਪਲੱਗਇਨ ਮੈਮੋਰੀ ਵਿੱਚ ਸਾਰੀਆਂ ਮੁੱਖ ਆਈਡੀਜ਼ ਨੂੰ ਕੈਚ ਕਰਦਾ ਹੈ। ਇਸ ਲਈ, ਇੱਕ ਨਵੀਂ ਕੁੰਜੀ ਬਣਾਉਣ ਤੋਂ ਬਾਅਦ, ROB_1 ਨੂੰ ਸਰਵਰ 1 ਵਿੱਚ ਜੋੜਿਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਇਸ ਕੁੰਜੀ ਨੂੰ ਵਾਲਟ ਨੂੰ ਭੇਜਣ ਤੋਂ ਇਲਾਵਾ, ਕੁੰਜੀ ਨੂੰ ਕੈਸ਼ ਵਿੱਚ ਵੀ ਜੋੜਿਆ ਜਾਂਦਾ ਹੈ। ਹੁਣ, ਜਦੋਂ ਅਸੀਂ ਉਸੇ ਕੁੰਜੀ ਨੂੰ ਦੂਜੀ ਵਾਰ ਜੋੜਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਾਂ, keyring_vault ਜਾਂਚ ਕਰਦਾ ਹੈ ਕਿ ਕੀ ਕੈਸ਼ ਵਿੱਚ ਮੌਜੂਦ ਹੈ ਜਾਂ ਨਹੀਂ ਅਤੇ ਇੱਕ ਗਲਤੀ ਸੁੱਟਦੀ ਹੈ।

ਪਹਿਲੀ ਸਥਿਤੀ ਵਿੱਚ ਸਥਿਤੀ ਵੱਖਰੀ ਹੈ. ਸਰਵਰ1 ਅਤੇ ਸਰਵਰ 2 ਕੋਲ ਵੱਖਰੇ ਕੈਸ਼ ਹਨ। ਸਰਵਰ1 ਅਤੇ ਵਾਲਟ ਸਰਵਰ 'ਤੇ ਕੁੰਜੀ ਕੈਸ਼ ਵਿੱਚ ROB_1 ਨੂੰ ਜੋੜਨ ਤੋਂ ਬਾਅਦ, ਸਰਵਰ 2 'ਤੇ ਕੁੰਜੀ ਕੈਸ਼ ਸਿੰਕ ਤੋਂ ਬਾਹਰ ਹੈ। ਸਰਵਰ 2 'ਤੇ ਕੈਸ਼ ਵਿੱਚ ਕੋਈ ROB_1 ਕੁੰਜੀ ਨਹੀਂ ਹੈ। ਇਸ ਤਰ੍ਹਾਂ, ROB_1 ਕੁੰਜੀ keyring_key_store ਅਤੇ Vault ਸਰਵਰ ਨੂੰ ਲਿਖੀ ਜਾਂਦੀ ਹੈ, ਜੋ ਅਸਲ ਵਿੱਚ ਪਿਛਲੇ ਮੁੱਲ (!) ਨੂੰ ਓਵਰਰਾਈਟ ਕਰਦੀ ਹੈ। ਹੁਣ ਵਾਲਟ ਸਰਵਰ 'ਤੇ ROB_1 ਕੁੰਜੀ 543210987654321 ਹੈ। ਦਿਲਚਸਪ ਗੱਲ ਇਹ ਹੈ ਕਿ ਵਾਲਟ ਸਰਵਰ ਅਜਿਹੀਆਂ ਕਾਰਵਾਈਆਂ ਨੂੰ ਬਲੌਕ ਨਹੀਂ ਕਰਦਾ ਹੈ ਅਤੇ ਪੁਰਾਣੇ ਮੁੱਲ ਨੂੰ ਆਸਾਨੀ ਨਾਲ ਓਵਰਰਾਈਟ ਕਰਦਾ ਹੈ।

ਹੁਣ ਅਸੀਂ ਦੇਖ ਸਕਦੇ ਹਾਂ ਕਿ ਵਾਲਟ ਵਿੱਚ ਸਰਵਰ ਵਿਭਾਗੀਕਰਨ ਮਹੱਤਵਪੂਰਨ ਕਿਉਂ ਹੋ ਸਕਦਾ ਹੈ - ਜਦੋਂ ਤੁਸੀਂ keyring_udf ਦੀ ਵਰਤੋਂ ਕਰ ਰਹੇ ਹੋ ਅਤੇ ਵਾਲਟ ਵਿੱਚ ਕੁੰਜੀਆਂ ਨੂੰ ਸਟੋਰ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ। ਵਾਲਟ ਸਰਵਰ 'ਤੇ ਇਸ ਵਿਛੋੜੇ ਨੂੰ ਕਿਵੇਂ ਪ੍ਰਾਪਤ ਕਰਨਾ ਹੈ?

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

--server1:
vault_url = http://127.0.0.1:8200
secret_mount_point = server1_mount
token = (...)
vault_ca = (...)

--server2:
vault_url = http://127.0.0.1:8200
secret_mount_point = sever2_mount
token = (...)
vault_ca = (...)

ਇੱਥੇ ਤੁਸੀਂ ਵੇਖ ਸਕਦੇ ਹੋ ਕਿ ਸਰਵਰ1 ਅਤੇ ਸਰਵਰ 2 ਵੱਖ-ਵੱਖ ਮਾਊਂਟ ਪੁਆਇੰਟਾਂ ਦੀ ਵਰਤੋਂ ਕਰ ਰਹੇ ਹਨ। ਮਾਰਗਾਂ ਨੂੰ ਵੰਡਣ ਵੇਲੇ, ਸੰਰਚਨਾ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦੇਵੇਗੀ:

--server1:
vault_url = http://127.0.0.1:8200
secret_mount_point = mount_point/server1
token = (...)
vault_ca = (...)
--server2:
vault_url = http://127.0.0.1:8200
secret_mount_point = mount_point/sever2
token = (...)
vault_ca = (...)

ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਦੋਵੇਂ ਸਰਵਰ ਇੱਕੋ ਮਾਊਂਟ ਪੁਆਇੰਟ "mount_point" ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ, ਪਰ ਵੱਖ-ਵੱਖ ਮਾਰਗ। ਜਦੋਂ ਤੁਸੀਂ ਇਸ ਮਾਰਗ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਸਰਵਰ 1 'ਤੇ ਪਹਿਲਾ ਰਾਜ਼ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਵਾਲਟ ਸਰਵਰ ਆਪਣੇ ਆਪ ਇੱਕ "ਸਰਵਰ1" ਡਾਇਰੈਕਟਰੀ ਬਣਾਉਂਦਾ ਹੈ। ਸਰਵਰ 2 ਲਈ ਸਭ ਕੁਝ ਸਮਾਨ ਹੈ. ਜਦੋਂ ਤੁਸੀਂ mount_point/server1 ਜਾਂ mount_point/server2 ਵਿੱਚ ਆਖਰੀ ਰਾਜ਼ ਨੂੰ ਮਿਟਾਉਂਦੇ ਹੋ, ਤਾਂ ਵਾਲਟ ਸਰਵਰ ਉਹਨਾਂ ਡਾਇਰੈਕਟਰੀਆਂ ਨੂੰ ਵੀ ਮਿਟਾ ਦਿੰਦਾ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ ਮਾਰਗ ਵੱਖ ਕਰਨ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਸਿਰਫ਼ ਇੱਕ ਮਾਊਂਟ ਪੁਆਇੰਟ ਬਣਾਉਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਸੰਰਚਨਾ ਫਾਈਲਾਂ ਨੂੰ ਬਦਲਣਾ ਚਾਹੀਦਾ ਹੈ ਤਾਂ ਜੋ ਸਰਵਰ ਵੱਖਰੇ ਮਾਰਗਾਂ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਣ। HTTP ਬੇਨਤੀ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇੱਕ ਮਾਊਂਟ ਪੁਆਇੰਟ ਬਣਾਇਆ ਜਾ ਸਕਦਾ ਹੈ। CURL ਦੀ ਵਰਤੋਂ ਨਾਲ ਇਹ ਇਸ ਤਰ੍ਹਾਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ:

curl -L -H "X-Vault-Token: TOKEN" –cacert VAULT_CA
--data '{"type":"generic"}' --request POST VAULT_URL/v1/sys/mounts/SECRET_MOUNT_POINT

ਸਾਰੇ ਖੇਤਰ (TOKEN, VAULT_CA, VAULT_URL, SECRET_MOUNT_POINT) ਕੌਂਫਿਗਰੇਸ਼ਨ ਫਾਈਲ ਦੇ ਮਾਪਦੰਡਾਂ ਨਾਲ ਮੇਲ ਖਾਂਦੇ ਹਨ। ਬੇਸ਼ੱਕ, ਤੁਸੀਂ ਅਜਿਹਾ ਕਰਨ ਲਈ ਵਾਲਟ ਉਪਯੋਗਤਾਵਾਂ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ। ਪਰ ਮਾਊਂਟ ਪੁਆਇੰਟ ਦੀ ਰਚਨਾ ਨੂੰ ਸਵੈਚਲਿਤ ਕਰਨਾ ਆਸਾਨ ਹੈ। ਮੈਨੂੰ ਉਮੀਦ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਇਹ ਜਾਣਕਾਰੀ ਲਾਭਦਾਇਕ ਲੱਗੇਗੀ ਅਤੇ ਅਸੀਂ ਤੁਹਾਨੂੰ ਇਸ ਲੜੀ ਦੇ ਅਗਲੇ ਲੇਖਾਂ ਵਿੱਚ ਦੇਖਾਂਗੇ।

ਹੋਰ ਪੜ੍ਹੋ:

• ਸਿਸਬੈਂਚ ਅਤੇ ਬੇਤਰਤੀਬ ਵੇਰੀਏਬਲ ਦੀ ਵੰਡ

ਸਰੋਤ: www.habr.com