インメモリDB時代、プロセス内のメモリはどうやってセキュアにすればいいんですか？：Linuxユーザーも知らないと損する「Silicon Secured Memory」の基礎知識

SPARC/Solarisの“新発見”を紹介する「SPARC/Solaris World」。SPARC M7に搭載されている「SSM（Silicon Secured Memory：シリコンセキュアドメモリ）」って、そもそも何なのか？ MMU（Memory Management Unit：メモリ管理装置）との違いは？ SSMがどうやって攻撃を防ぐのか？ など、今回はより技術的な観点でSPARC/Solarisの魅力を紹介します。

[PR／＠IT]

PR

今回は、セキュリティ勉強会に参加してきました

こんにちは。日本オラクルの増田佑菜（ますだ ゆうな）です。

SPARC/Solarisの“新発見”を紹介する「SPARC/Solaris World」。今回は、日本オラクル社内で行われたセキュリティ勉強会に参加してきたので、そこで学んだことを皆さんにお伝えします。SPARC M7に搭載されている「SSM（Silicon Secured Memory：シリコンセキュアドメモリ）」って、そもそも何なのか？ MMU（Memory Management Unit：メモリ管理装置）との違いは？ SSMがどうやって攻撃を防ぐのか？ など、今回はより技術的な観点でSPARC/Solarisの魅力を紹介します！

ますます巧妙化・多様化する攻撃

　今IT業界でホットな話題は、やはりセキュリティ（図1）。このような例から分かるのは、従来のファイアウォールなどでネットワークからの侵入を防ぐだけでは不十分で、暗号化を徹底的に実施したり、さらに多層防壁によって、万一侵入されても、被害を最小限にとどめたりすることが重要といわれています。

図1　大規模データ侵害の時代

　また、最近の傾向は、狙いを決めた攻撃を受けることが多いようです。外部のネットワークからの攻撃に加え、故意／過失にかかわらず内部からも攻撃される場合が増えています。

　こういった攻撃は一時的なものではなく、1年にわたって行われていた例も報告されており、さまざまな方法、手順、ツールを使って少しずつ行われる場合があるのです！

ソフトウェアには脆弱性のバグがつきもの

　また厄介なのが、われわれ人間が作ったものには、バグがつきものということなんです。たとえセキュリティの専門家が作ったソフトウェアであっても、バグによって「HeartBleed（ハートブリード）」「VENOM（Virtualized Environment Neglected Operations Manipulation：ベノム）」という致命的な問題を露呈してしまう例が後を絶ちません。

　現在ほとんどのシステムで採用している暗号通信のソフトウェアとしてOpenSSLがあります。セキュアにネットワーク上で通信するはずのOpenSSLでしたが、2014年の4月にHeartBleedという脆弱性のバグが発覚しました。バッファオーバーラン（バッファオーバーフロー）を悪用することによってサーバへの不正侵入を許してしまったのです。

図2　HeartBleed

　VENOMは、XenやKVMなどの仮想化プラットフォームに利用されているオープンソースのエミュレーター「QEMU」に発見された仮想マシンを抜け出すことが可能な脆弱性のバグです。2015年5月に発見されました。悪用されれば、同一のハイパーバイザー上に同居している他の仮想マシンやホストOSにアクセスされ、任意のコードを実行される恐れがあります。

SSM（Silicon Secured Memory：シリコンセキュアドメモリ）って？

　でも、オラクルは既に6年も前に、将来、インメモリデータベース時代が到来したときに、何が起こるか考えていました。「マルウェアなどによって、従来のディスクベースのデータベースよりもいとも簡単にインメモリデータベースの内容は盗まれてしまうんじゃないか」と。多階層のストレージですと、データが分散しており、その配置も複雑なのに対して、インメモリデータベースはメインメモリをのぞかれてしまえば、全てのデータを盗まれてしまいます。

　そこでオラクルは、サンマイクロシステムズ（以下、サン）と統合したときに、マルウェアによる漏えいや、自身のバグによるデータ破壊の対策をサンの設計するCPUに組み込む計画を立てました。

　この計画による成果がSPARC M7（以下、M7）で実現されているソフトウェアインシリコンの1つである「SSM（Silicon Secured Memory：シリコンセキュアドメモリ）」なんですね。オラクルはM7の開発とOracle Database 12cの開発を平行して行い、両製品のリリース時に、SSMによって守られたM7上のOracle Database 12cを出荷することができました。さらに、SSMは応用範囲が広く、さまざまなセキュリティリスクから守れる可能性を引き出しているのです。

MMUとSSM

　だんだん難しくなってきましたが、まず今日におけるコンピュータのメモリ管理をおさらいすると、一部の小規模組み込み用途を除いて、今のコンピュータ／CPUはMMU（Memory Management Unit：メモリ管理装置）を装備しています。MMUは物理メモリアドレスと仮想メモリアドレスの変換や、個々のメモリブロックごとの保護などを実行するんですね。このMMUはOSによって管理され、コンピュータで実行される数多くの処理単位（UNIX系のOSでは「プロセス」と呼ぶ）にメモリを割り当て、プロセス間やOS自身のメモリを保護するようにMMUを設定します。

　つまり、このプロセス同士の間で、メモリをのぞいたり、書き換えたりすることはできないようになっています（特段設定した共有メモリを除く）。皆さんが、ノートPCなどを使っていて、ある処理（例えばプレゼン作成ツール）の動きがおかしくなったり、落ちたりしてしまっても、一緒に動かしていた文書作成ツールやOS自身は問題なく継続して使えるのは、MMUが保護をしているからなんです！

　先ほどのSSMが対象とするのは、この個々のプロセスの中です。昨今のソフトウェアは複雑で、さまざまな層からなっていますが、バグやマルウェアを含む、おかしな動きをする部品があった場合、プロセス内はMMUでは保護できないみたいです。

SSMがどうやって攻撃を防ぐのか？

　個々のプロセスで動くソフトウェアは、メモリを使うときに目的ごとに割り当てるのが一般的です。SSMでは、これらの目的別のプロセス内のメモリに対して、個別の印を付けます。この印のことを一般的には「カラー」と呼び、メモリの領域を色分けしているようなものです。カラーを割り当てる際に、カラーごとに鍵を割り当ててメモリを割り当てたプログラムに返します。割り当てられたメモリ領域は、正しい鍵をもっていないとアクセスできないように設定されます。

　例えば、64バイト割り当てられた領域に対して、誤って64バイト以上のメモリにアクセスしようとすると、そこは別の目的で割り当てられたメモリになるため、色が違い、鍵が合わないことになります。この単純な仕掛けより、隣り合ったメモリの領域には異なったカラーが割り振られ、バッファオーバーランした場合にはそれを検出し、プロセスを強制終了することによって、HeartBleedのようなデータ漏えいを未然に防ぐことができます（図3）。

図3　SSM：きめ細かいメモリ保護

SSMの何がすごいのか？

　昔からC／C++などでシステムを開発してきた大先輩によると、「SSMができることは以前から、専用のツールが存在していて検出できた」とのことです。「こういったバッファオーバーランやローグポインタ問題は昔からありましたが、発見が難しいためプログラマーを悩ませてきた」と言っていました。だから、プログラム開発支援システムが、こういった問題を検出するツールを昔から作っています。でも、これらはほとんどがソフトウェアによる処理なので、10倍以上の速度低下が起こってしまうなど、それ専用にコンパイルし直さないといけなかったんですね。

　でも、SSMはこれを、何とほとんど速度低下のない状態で実現してしまうのです。このために、M7上で実行されるOracle Database 12cはデバッグのためではなく、本番実行でもSSMでの保護を使うように設定されています。つまり、従来のツールはあくまでもデバッグのツールであり、普段使うためには不向きであったのに対しSSMはセキュリティを強化するために、常用できる用に速度低下を招かないように設計／実装されているのです。

　例えば、他のメモリバリデーションツールでは約3時間かかるようなバグの特定も、SSMとOracle Solaris Studioのツールを使えば約1分で済みます。約180倍も高速なんです。

Solaris 11.3になったら……

　SSMを使うためには基本的にソフトウェア側を変更する必要があります。例えば、Oracle Database 12cはインメモリデータベースが展開されているSGA領域（SGA = Shared Global Area：Oracle Databaseを構成するプロセス間で共有するメモリでバッファキャッシュや、インメモリデータベース自身などに使われます）をSSMで保護するように書き換えられています。何と、新しいSolaris 11.3では、それに必要なAPIを公開しているんです！

　一方で、対象のソフトウェアがそれほど複雑ではない場合、メモリ管理をOSが提供するlibcのmallocだけで行っていることが多いと思います。その場合は、SSM用に書き換えられたmallocをSolaris 11.3では用意しているので、動的リンクのときに指定するだけで有効になります。

　簡単なC言語で書いた例を用意しましたので、ご覧ください。なお、SolarisではSSMの機能を「ADI（Application Data Integrity）」と呼んでいます。

man page:  libadimalloc(3LIB)

参考：libadimalloc - man pages section 3: Library Interfaces and Headers

man page:  adi(3C)

参考：adi - man pages section 3: Basic Library Functions

図4　バイナリそのままでもSSMの有効化が可能な例

　詳しくはSolaris 11.3のドキュメントを参照してください。

※ 本編で紹介したように SPARC/Solaris には独自のセキュリティの機能が搭載されておりますが、Linux しか使い方が分からないと思っている方も少なくないと思います。そこで、Linuxユーザ のためのSolaris入門書として活用できるホワイトペーパーをご用意しましたので、あわせてこちらからご覧下さい。

＞＞ホワイトペーパー閲覧ページへ

「Solarisは使い方が分からない」という方へ

　コンピュータのセキュリティはすごく重要な課題です！ SPARC M7はSSMを搭載し、企業により強固なIT基盤を築くための重要な技術を提供しているんですね。

　昨今はLinuxユーザーの多くがSolarisは使い方が分からないと思っていらっしゃるようですが、そうでもないことが分かる資料を用意しましたので、併せてご覧ください。