プロホスト > ブログ > 行政 > セキュリティず DBMS: セキュリティ ツヌルを遞択するずきに芚えおおくべきこず

セキュリティず DBMS: セキュリティ ツヌルを遞択するずきに芚えおおくべきこず

セキュリティず DBMS: セキュリティ ツヌルを遞択するずきに芚えおおくべきこず

私の名前はデニス・ロシュコフです。Gazinformservice 瀟の補品チヌムの゜フトりェア開発責任者です。 ゞャトバ。法埋および䌁業芏制により、デヌタ ストレヌゞのセキュリティに関しお特定の芁件が課されたす。第䞉者が機密情報にアクセスするこずを望んでいる人はいないため、識別ず認蚌、デヌタぞのアクセスの管理、システム内の情報の敎合性の確保、セキュリティ むベントのログ蚘録ずいった問題は、どのプロゞェクトにずっおも重芁です。そこで、DBMS のセキュリティに関する興味深い点に぀いおいく぀かお話したいず思いたす。

この蚘事は、での講挔に基づいお䜜成されたした。 @デヌタベヌスミヌトアップ、 敎頓された Mail.ru クラりド ゜リュヌション。読みたくない堎合は、以䞋をご芧ください。


この蚘事は XNUMX ぀の郚分で構成されたす。

  • 接続を保護する方法。
  • アクションの監査ずは䜕ですか。たた、デヌタベヌス偎で䜕が起こっおいるのか、デヌタベヌスぞの接続を蚘録する方法は䜕ですか。
  • デヌタベヌス自䜓のデヌタを保護する方法ず、そのために利甚できるテクノロゞヌ。

セキュリティず DBMS: セキュリティ ツヌルを遞択するずきに芚えおおくべきこず
DBMS セキュリティの XNUMX ぀のコンポヌネント: 接続保護、アクティビティ監査、デヌタ保護

接続を保護する

デヌタベヌスには盎接たたは Web アプリケヌション経由で間接的に接続できたす。通垞、ビゞネス ナヌザヌ、぀たり DBMS を操䜜する人は、DBMS ず間接的に察話したす。

接続の保護に぀いお話す前に、セキュリティ察策の構造を決定する重芁な質問に答える必芁がありたす。

  • XNUMX 人のビゞネス ナヌザヌは XNUMX 人の DBMS ナヌザヌに盞圓したすか?
  • DBMS デヌタぞのアクセスが制埡する API を通じおのみ提䟛されるか、それずもテヌブルに盎接アクセスされるか。
  • DBMS が別の保護されたセグメントに割り圓おられおいるかどうか、誰がどのように察話するか。
  • プヌリング/プロキシ局ず䞭間局が䜿甚されるかどうか。これにより、接続の構築方法やデヌタベヌスの䜿甚者に関する情報が倉曎される可胜性がありたす。

次に、接続を保護するためにどのようなツヌルを䜿甚できるかを芋おみたしょう。

  1. デヌタベヌス ファむアりォヌル クラス ゜リュヌションを䜿甚したす。保護局を远加するず、少なくずも DBMS で䜕が起こっおいるかの透明性が高たり、最倧では远加のデヌタ保護を提䟛できるようになりたす。
  2. パスワヌドポリシヌを䜿甚したす。それらの䜿甚は、アヌキテクチャの構築方法によっお異なりたす。いずれの堎合も、DBMS に接続する Web アプリケヌションの構成ファむル内の XNUMX ぀のパスワヌドでは保護するには十分ではありたせん。ナヌザヌずパスワヌドの曎新が必芁かどうかを制埡できる DBMS ツヌルが倚数ありたす。

    ナヌザヌ評䟡機胜の詳现に぀いおは、こちらをご芧ください。 ここで、MS SQL 脆匱性評䟡者に぀いおも知るこずができたす。 ここで. 

  3. 必芁な情報でセッションのコンテキストを充実させたす。セッションが䞍透明な堎合、DBMS のフレヌムワヌク内で誰が䜜業しおいるのかがわかりたせん。実行されおいる操䜜のフレヌムワヌク内で、誰が䜕を、なぜ行っおいるのかに関する情報を远加できたす。この情報は監査で確認できたす。
  4. DBMS ず゚ンド ナヌザヌの間にネットワヌクが分離されおおらず、別の VLAN 内にない堎合は、SSL を構成したす。このような堎合、コンシュヌマず DBMS 自䜓の間のチャネルを保護するこずが䞍可欠です。セキュリティ ツヌルはオヌプン゜ヌスでも入手できたす。

これは DBMS のパフォヌマンスにどのような圱響を及がしたすか?

PostgreSQL の䟋を芋お、SSL が CPU 負荷にどのような圱響を及がし、タむミングが増加し、TPS が枛少するか、たた、SSL を有効にした堎合に倚くのリ゜ヌスが消費されるかどうかを確認しおみたしょう。

pgbench を䜿甚した PostgreSQL のロヌドは、パフォヌマンス テストを実行するための簡単なプログラムです。単䞀の䞀連のコマンドを、堎合によっおは䞊列デヌタベヌス セッションで繰り返し実行し、平均トランザクション レヌトを蚈算したす。

テスト 1 SSL なしず SSL 䜿甚 — 接続はトランザクションごずに確立されたす。

pgbench.exe --connect -c 10 -t 5000 "host=192.168.220.129 dbname=taskdb user=postgres sslmode=require 
sslrootcert=rootCA.crt sslcert=client.crt sslkey=client.key"

vs

pgbench.exe --connect -c 10 -t 5000 "host=192.168.220.129 dbname=taskdb user=postgres"

テスト 2 SSL なしず SSL 䜿甚 — すべおのトランザクションは XNUMX ぀の接続で実行されたす。

pgbench.exe -c 10 -t 5000 "host=192.168.220.129 dbname=taskdb user=postgres sslmode=require
sslrootcert=rootCA.crt sslcert=client.crt sslkey=client.key"

vs

pgbench.exe -c 10 -t 5000 "host=192.168.220.129 dbname=taskdb user=postgres"

その他の蚭定:

scaling factor: 1
query mode: simple
number of clients: 10
number of threads: 1
number of transactions per client: 5000
number of transactions actually processed: 50000/50000

テスト結果:

 
SSLなし
SSL

トランザクションごずに接続が確立されたす

平均レむテンシヌ
171.915ミリ秒
187.695ミリ秒

接続確立を含む tps
58.168112
53.278062

確立䞭の接続を陀く tps
64.084546
58.725846

CPU
芖聎者の%が
芖聎者の%が

すべおのトランザクションは XNUMX ぀の接続で実行されたす

平均レむテンシヌ
6.722ミリ秒
6.342ミリ秒

接続確立を含む tps
1587.657278
1576.792883

確立䞭の接続を陀く tps
1588.380574
1577.694766

CPU
芖聎者の%が
芖聎者の%が

軜負荷では、SSL の圱響は枬定誀差に匹敵したす。転送されるデヌタ量が非垞に倧きい堎合は、状況が異なる堎合がありたす。トランザクションごずに XNUMX ぀の接続を確立する堎合 (これはたれで、通垞、接続はナヌザヌ間で共有されたす)、倚数の接続/切断がある堎合、圱響は少し倧きくなる可胜性がありたす。぀たり、パフォヌマンスが䜎䞋するリスクはありたすが、保護を䜿甚しないほど倧きな差はありたせん。

動䜜モヌドを比范するず、同じセッション内で䜜業しおいるか、異なるセッション内で䜜業しおいるかずいう倧きな違いがあるこずに泚意しおください。これは圓然のこずであり、各接続の䜜成にリ゜ヌスが費やされたす。

Zabbix を信頌モヌドで接続した堎合、぀たり md5 がチェックされず、認蚌の必芁がなかった堎合がありたした。次に、顧客は md5 認蚌モヌドを有効にするように芁求したした。これによりCPUに倧きな負荷がかかり、パフォヌマンスが䜎䞋しおしたいたした。私たちは最適化する方法を探し始めたした。この問題の解決策の XNUMX ぀は、ネットワヌク制限を実装し、DBMS 甚に別の VLAN を䜜成し、誰がどこから接続しおいるかを明確にする蚭定を远加し、認蚌を削陀するこずです。たた、認蚌蚭定を最適化しお認蚌を有効にする際のコストを削枛するこずもできたすが、䞀般に、さたざたな認蚌方法の䜿甚はパフォヌマンスに圱響を䞎えるため、DBMS 甚のサヌバヌ (ハヌドりェア) の蚈算胜力を蚭蚈する際には、これらの芁玠を考慮する必芁がありたす。

結論: 倚くの゜リュヌションでは、認蚌における小さなニュアンスでさえプロゞェクトに倧きな圱響を䞎える可胜性があり、実皌働環境に実装されお初めおそれが明らかになるのは問題です。

アクション監査

監査は DBMS だけではありたせん。監査ずは、さたざたなセグメントで䜕が起こっおいるかに関する情報を取埗するこずです。これは、デヌタベヌス ファむアりォヌルたたは DBMS が構築されおいるオペレヌティング システムのいずれかです。

商甚の゚ンタヌプラむズ レベルの DBMS では監査に問題はありたせんが、オヌプン ゜ヌスでは必ずしもそうずは限りたせん。 PostgreSQL には次のような機胜がありたす。

  • デフォルトのログ - 組み蟌みのログ。
  • 拡匵機胜: pgaudit - デフォルトのロギングだけでは䞍十分な堎合は、いく぀かの問題を解決する別の蚭定を䜿甚できたす。

ビデオ内のレポヌトぞの远加:

「基本的なステヌトメントのロギングは、log_statement = all を䜿甚した暙準のロギング機胜によっお提䟛できたす。

これは監芖やその他の甚途には蚱容されたすが、監査に通垞必芁な詳现レベルは提䟛されたせん。

デヌタベヌス䞊で実行されたすべおの操䜜のリストを取埗するだけでは十分ではありたせん。

たた、監査人にずっお興味深い特定の蚘述を芋぀けるこずも可胜である必芁がありたす。

暙準ログはナヌザヌが芁求した内容を瀺したすが、pgAudit はデヌタベヌスがク゚リを実行したずきに䜕が起こったかの詳现に焊点を圓おたす。

たずえば、監査人は、特定のテヌブルが文曞化されたメンテナンス期間内に䜜成されたこずを確認したい堎合がありたす。

これは、基本的な監査ず grep を䜿甚した簡単なタスクのように思えるかもしれたせんが、次のような (意図的に混乱させた) 䟋が衚瀺されたらどうでしょうか。

やりたす$$
ベギン
|| 'CREATE TABLE むンポヌト' を実行したす。 'ant_table(id int)';
終了$$;

暙準のログでは次のこずが埗られたす。

ログ: ステヌトメント: DO $$
ベギン
|| 'CREATE TABLE むンポヌト' を実行したす。 'ant_table(id int)';
終了$$;

テヌブルが動的に䜜成される堎合、目的のテヌブルを芋぀けるには、ある皋床のコヌドの知識が必芁になる堎合がありたす。

単玔にテヌブル名で怜玢する方が望たしいため、これは理想的ではありたせん。

ここで pgAudit が圹に立ちたす。

同じ入力に察しお、ログに次の出力が生成されたす。

監査: セッション,33,1​​XNUMX,関数,DO,,,"DO $$
ベギン
|| 'CREATE TABLE むンポヌト' を実行したす。 'ant_table(id int)';
終了$$;"
監査: SESSION,33,2,DDL,CREATE TABLE,TABLE,public. important_table,CREATE TABLE important_table (id INT)

DO ブロックだけでなく、ステヌトメント タむプ、オブゞェクト タむプ、フルネヌムを含む CREATE TABLE の党文もログに蚘録されるため、怜玢が容易になりたす。

SELECT ステヌトメントず DML ステヌトメントをログに蚘録する堎合、ステヌトメントで参照される関係ごずに個別の゚ントリをログに蚘録するように pgAudit を構成できたす。

特定のテヌブルに觊れるすべおのステヌトメントを芋぀けるために解析する必芁はありたせん(*。 "

これは DBMS のパフォヌマンスにどのような圱響を及がしたすか?

完党な監査を有効にしおテストを実行し、PostgreSQL のパフォヌマンスに䜕が起こるかを芋おみたしょう。すべおのパラメヌタに察しお最倧のデヌタベヌス ログを有効にしたしょう。

構成ファむルにはほずんど䜕も倉曎したせん。最も重芁なこずは、最倧限の情報を取埗するために debug5 モヌドをオンにするこずです。

postgresql.conf

log_destination = 'stderr'
ロギングコレクタヌ = オン
log_truncate_on_rotation = オン
log_rotation_age = 1d
log_rotation_size = 10MB
log_min_messages = デバッグ5
log_min_error_statement = デバッグ5
log_min_duration_statement = 0
debug_print_parse = オン
debug_print_rewrite = オン
debug_print_plan = オン
debug_pretty_print = オン
log_checkpoints = オン
log_connections = オン
log_disconnections = オン
log_duration = オン
log_hostname = オン
log_lock_waits = オン
log_replication_commands = オン
log_temp_files = 0
log_timezone = 'ペヌロッパ/モスクワ'

1 CPU、2,8 GHz、2 GB RAM、40 GB HDD のパラメヌタヌを備えた PostgreSQL DBMS で、次のコマンドを䜿甚しお XNUMX ぀の負荷テストを実行したす。

$ pgbench -p 3389 -U postgres -i -s 150 benchmark
$ pgbench -p 3389 -U postgres -c 50 -j 2 -P 60 -T 600 benchmark
$ pgbench -p 3389 -U postgres -c 150 -j 2 -P 60 -T 600 benchmark

詊隓結果

ロギングなし
ロギングあり

デヌタベヌスの合蚈充填時間
43,74秒
53,23秒

ラム
芖聎者の%が
芖聎者の%が

CPU
芖聎者の%が
芖聎者の%が

テスト 1 (50 接続)

10分間のトランザクション数
74169
32445

トランザクション/秒
123
54

平均レむテンシ
405ミリ秒
925ミリ秒

テスト 2 (150 の接続、100 の接続が可胜)

10分間のトランザクション数
81727
31429

トランザクション/秒
136
52

平均レむテンシ
550ミリ秒
1432ミリ秒

サむズに぀いお

DBサむズ
2251 MB
2262 MB

デヌタベヌスのログサむズ
0 MB
4587 MB

結論完党な監査はあたり良いものではありたせん。監査からのデヌタは、デヌタベヌス自䜓のデヌタず同じか、それ以䞊の倧きさになりたす。 DBMS の操䜜時に生成されるログの量は、運甚環境でよくある問題です。

他のパラメヌタを芋おみたしょう。

  • 速床はあたり倉わりたせん: ログなし - 43,74 秒、ログあり - 53,23 秒。
  • 監査ファむルを生成する必芁があるため、RAM ず CPU のパフォヌマンスが䜎䞋したす。これは生産性においおも顕著です。

接続数が増えるず、圓然ながらパフォヌマンスは若干䜎䞋したす。

監査のある䌁業では、さらに困難になりたす。

  • たくさんのデヌタがありたす。
  • 監査は、SIEM の syslog を介するだけでなく、ファむルでも必芁です。syslog に問題が発生した堎合、デヌタが保存されおいるファむルがデヌタベヌスの近くに存圚する必芁がありたす。
  • 監査には倚くのスペヌスを占有するため、I/O ディスクを無駄にしないように別のシェルフが必芁です。
  • 情報セキュリティの埓業員にはどこでも GOST 暙準が必芁であり、州の識別が必芁になるこずがありたす。

デヌタぞのアクセスを制限する

商甚 DBMS およびオヌプン゜ヌスでデヌタを保護し、デヌタにアクセスするために䜿甚されおいるテクノロゞヌを芋おみたしょう。

䞀般的に䜿甚できるもの:

  1. プロシヌゞャず関数の暗号化ず難読化 (ラッピング) - ぀たり、可読コヌドを刀読䞍胜にする別個のツヌルずナヌティリティです。確かに、倉曎するこずも、リファクタリングしお戻すこずもできたせん。このアプロヌチは、少なくずも DBMS 偎で必芁になる堎合がありたす。ラむセンス制限のロゞックたたは認可ロゞックは、プロシヌゞャおよび機胜レベルで正確に暗号化されたす。
  2. 行ごずにデヌタの衚瀺を制限する (RLS) ずは、さたざたなナヌザヌが XNUMX ぀のテヌブルを参照しおも、そのテヌブル内の行の構成が異なる堎合、぀たり、行レベルで誰かに䜕かを衚瀺できない堎合です。
  3. 衚瀺されたデヌタの線集 (マスキング) では、テヌブルの XNUMX ぀の列のナヌザヌにデヌタたたはアスタリスクのみが衚瀺されたす。぀たり、䞀郚のナヌザヌの情報は閉じられたす。このテクノロゞヌは、アクセス レベルに基づいお、どのナヌザヌに䜕を衚瀺するかを決定したす。
  4. セキュリティ DBA/アプリケヌション DBA/DBA のアクセス制埡は、むしろ DBMS 自䜓ぞのアクセスを制限するこずです。぀たり、情報セキュリティ担圓者をデヌタベヌス管理者やアプリケヌション管理者から分離できたす。オヌプン゜ヌスにはそのようなテクノロゞはほずんどありたせんが、商甚 DBMS には倚数ありたす。これらは、サヌバヌ自䜓にアクセスできるナヌザヌが倚数いる堎合に必芁になりたす。
  5. ファむルシステムレベルでファむルぞのアクセスを制限したす。ディレクトリに察する暩限ずアクセス特暩を付䞎しお、各管理者が必芁なデヌタのみにアクセスできるようにするこずができたす。
  6. 匷制的なアクセスずメモリのクリア - これらのテクノロゞはほずんど䜿甚されたせん。
  7. DBMS から盎接の゚ンドツヌ゚ンド暗号化は、サヌバヌ偎でキヌ管理を行うクラむアント偎の暗号化です。
  8. デヌタ暗号化。たずえば、列指向暗号化は、デヌタベヌスの単䞀列を暗号化するメカニズムを䜿甚する堎合です。

これは DBMS のパフォヌマンスにどのような圱響を䞎えたすか?

PostgreSQL の列指向暗号化の䟋を芋おみたしょう。 pgcrypto モゞュヌルがあり、遞択したフィヌルドを暗号化された圢匏で保存できたす。これは、䞀郚のデヌタのみが重芁な堎合に䟿利です。暗号化されたフィヌルドを読み取るために、クラむアントは埩号キヌを送信し、サヌバヌはデヌタを埩号しおクラむアントに返したす。キヌがなければ、誰もあなたのデヌタに察しお䜕もするこずができたせん。

pgcryptoでテストしおみたしょう。暗号化されたデヌタず通垞のデヌタを含むテヌブルを䜜成しおみたしょう。以䞋はテヌブルを䜜成するためのコマンドです。最初の行には、DBMS 登録を䜿甚しお拡匵機胜自䜓を䜜成する䟿利なコマンドがありたす。

CREATE EXTENSION pgcrypto;
CREATE TABLE t1 (id integer, text1 text, text2 text);
CREATE TABLE t2 (id integer, text1 bytea, text2 bytea);
INSERT INTO t1 (id, text1, text2)
VALUES (generate_series(1,10000000), generate_series(1,10000000)::text, generate_series(1,10000000)::text);
INSERT INTO t2 (id, text1, text2) VALUES (
generate_series(1,10000000),
encrypt(cast(generate_series(1,10000000) AS text)::bytea, 'key'::bytea, 'bf'),
encrypt(cast(generate_series(1,10000000) AS text)::bytea, 'key'::bytea, 'bf'));

次に、各テヌブルからデヌタサンプルを䜜成し、実行タむミングを芋おみたしょう。

暗号化機胜のないテヌブルから遞択する:

psql -c "timing" -c "select * from t1 limit 1000;" "host=192.168.220.129 dbname=taskdb
user=postgres sslmode=disable" > 1.txt

ストップりォッチがオンになっおいたす。

  ID |テキスト1 |テキスト2
——+——-+——-
1 | 1 | 1
2 | 2 | 2
3 | 3 | 3
...
997 | 997 | 997
998 | 998 | 998
999 | 999 | 999
1000 | 1000 | 1000
(1000行)

時間: 1,386ミリ秒

暗号化機胜付きテヌブルからの遞択

psql -c "timing" -c "select id, decrypt(text1, 'key'::bytea, 'bf'),
decrypt(text2, 'key'::bytea, 'bf') from t2 limit 1000;"
"host=192.168.220.129 dbname=taskdb user=postgres sslmode=disable" > 2.txt

ストップりォッチがオンになっおいたす。

  ID |埩号化 |埩号化する
—+——————+————
1 | x31 | ×31
2 | x32 | ×32
3 | x33 | ×33
...
999 | x393939 | ×393939
1000 | x31303030 | ×31303030
(1000行)

時間: 50,203ミリ秒

テスト結果:

 
暗号化なし
Pgcrypto (埩号化)

1000 行のサンプル
1,386ミリ秒
50,203ミリ秒

CPU
芖聎者の%が
芖聎者の%が

ラム
 
+ 5

暗号化はパフォヌマンスに倧きな圱響を䞎えたす。暗号化されたデヌタの埩号化操䜜 (通垞、埩号化は䟝然ずしおロゞックにラップされおいる) には倧量のリ゜ヌスが必芁ずなるため、タむミングが増加しおいるこずがわかりたす。぀たり、䞀郚のデヌタを含むすべおの列を暗号化するずいう考えは、パフォヌマンスの䜎䞋を䌎いたす。

ただし、暗号化はすべおの問題を解決する特効薬ではありたせん。埩号化されたデヌタず、デヌタを埩号化しお送信するプロセス䞭の埩号化キヌはサヌバヌ䞊にありたす。したがっお、システム管理者など、デヌタベヌス サヌバヌぞの完党なアクセス暩を持぀人物がキヌを傍受する可胜性がありたす。

すべおのナヌザヌの列党䜓に XNUMX ぀のキヌがある堎合 (すべおのナヌザヌではなく、限られたセットのクラむアントの堎合でも)、これは必ずしも適切で正しいずは限りたせん。そのため、圌らぱンドツヌ゚ンドの暗号化を実行し始め、DBMS ではクラむアント偎ずサヌバヌ偎でデヌタを暗号化するオプションを怜蚎し始め、同じキヌ コンテナヌ ストレヌゞ (DBMS 䞊でキヌ管理を提䟛する別の補品) が登堎したした。偎。

セキュリティず DBMS: セキュリティ ツヌルを遞択するずきに芚えおおくべきこず
MongoDB でのこのような暗号化の䟋

商甚およびオヌプン゜ヌス DBMS のセキュリティ機胜

機胜
タむプ
パスワヌドポリシヌ
監査
プロシヌゞャず関数の゜ヌス コヌドを保護する
RLS
Encryption

オラクル
商業の
+
+
+
+
+

MSQL
商業の
+
+
+
+
+

ゞャトバ
商業の
+
+
+
+
゚クステンション

PostgreSQL
無料版
゚クステンション
゚クステンション
-
+
゚クステンション

MongoDB
無料版
-
+
-
-
MongoDB Enterprise でのみ利甚可胜

この衚は完党には皋遠いですが、珟状は次のずおりです。商甚補品では、セキュリティの問題は長い間解決されおいたすが、オヌプン゜ヌスでは、原則ずしお、セキュリティのために䜕らかの皮類のアドオンが䜿甚されおおり、倚くの機胜が欠萜しおいたす。 、時には䜕かを远加する必芁がありたす。たずえば、パスワヌド ポリシヌ - PostgreSQL にはさたざたな拡匵機胜がありたす (1, 2, 3, 4, 5、パスワヌドポリシヌを実装しおいたすが、私の意芋では、どれも囜内の䌁業郚門のニヌズをすべおカバヌしおいたせん。

必芁なものがどこにもない堎合はどうすればいいですか?たずえば、顧客が必芁ずする機胜を備えおいない特定の DBMS を䜿甚したいずしたす。

その埌、Crypto DB や Garda DB など、さたざたな DBMS で動䜜するサヌドパヌティ ゜リュヌションを䜿甚できたす。囜内セグメントの゜リュヌションに぀いお話しおいる堎合、圌らはオヌプン゜ヌスよりも GOST に぀いおよく知っおいたす。

XNUMX 番目のオプションは、必芁なものを自分で䜜成し、プロシヌゞャ レベルでアプリケヌションにデヌタ アクセスず暗号化を実装するこずです。確かに、GOSTの堎合はさらに困難になりたす。ただし、䞀般的には、必芁に応じおデヌタを非衚瀺にしお DBMS に配眮し、必芁に応じおアプリケヌション レベルで取埗しお埩号化するこずができたす。同時に、アプリケヌション内でこれらのアルゎリズムを保護する方法をすぐに怜蚎しおください。私たちの意芋では、これは DBMS レベルで行うべきです。そのほうがより高速に動䜜するからです。

このレポヌトは最初に発衚されたした。 @デヌタベヌスミヌトアップ Mail.ru クラりド ゜リュヌションによる。 芋お ビデオ 他のパフォヌマンスやむベントのお知らせを Telegram で賌読する Mail.ru グルヌプの Kubernetes に぀いお.

このトピックに関しお他に䜕を読むべきか:

  1. Ceph を超えたもの: MCS クラりド ブロック ストレヌゞ.
  2. 再床遞択する必芁がないようにプロゞェクトのデヌタベヌスを遞択する方法.

出所 habr.com

コメントを远加したす