This translation is community contributed and may not be up to date. We only maintain the English version of the documentation. Read this manual in English
アプリケーションのセキュリティは、安全な開発手法からリリース後のゲームコンテンツの保護まで、幅広い分野を扱うテーマです。このマニュアルでは、Defold エンジン、ツール、サービスを使用する際のアプリケーションセキュリティという観点から、次の分野を説明します。
ほとんどの開発者が抱く懸念の1つは、自分の作品を盗用からどう守るかということです。法的な観点では、著作権、特許、商標によって、ビデオゲームの知的財産のさまざまな側面を保護できます。著作権は創作物を配布する独占的な権利を所有者に与え、特許は発明を保護し、商標は名前、記号、ロゴを保護します。
ゲームという創作物を保護するために、技術的な対策を講じたい場合もあるでしょう。ただし、ゲームがプレイヤーの手に渡ると、アセット(asset)を抽出する方法を見つけられる可能性があることを念頭に置く必要があります。ゲームのアプリケーションやファイルをリバースエンジニアリングするだけでなく、テクスチャやモデルが GPU に送られるとき、あるいはその他のアセットがメモリに読み込まれるときに、ツールを使って抽出することもできます。
このため、Defold としては、ユーザーがゲームのアセットを抽出しようと決意すれば、それは実現できるという立場を基本としています。
開発者は独自の保護対策を追加してアセットの抽出を難しくできます。 ただし、不可能にはできません。通常は、さまざまな暗号化や難読化の手法によってゲームのアセットを保護し、隠します。
ソースコードの難読化は、プログラムの出力に影響を与えずに、人間がソースコードを理解しにくくする自動処理です。通常は盗用から保護することを目的としますが、チートを難しくする目的もあります。
Defold では、ビルド前の処理として、または Defold のビルド処理に組み込む形で、ソースコードを難読化できます。ビルド前に難読化する場合は、Defold のビルド処理が始まる前に、難読化ツールを使ってソースコードを難読化します。
一方、ビルド時の難読化は、Lua ビルダープラグイン(Lua builder plugin)を使ってビルド処理に組み込みます。Lua ビルダープラグインは、元のソースコードを入力として受け取り、難読化したソースコードを出力として返します。ビルド時の難読化の一例として、GitHub で公開されている Prometheus Lua 難読化ツールを基にした Prometheus 拡張があります。以下に、Prometheus を使って短いコードを強力に難読化する例を示します(このような高度な難読化は、Lua コードの実行時のパフォーマンスに影響する点に注意してください)。
例:
function init(self)
print("hello")
test.greet("Bob")
end
難読化された出力:
local v={"+qdW","ZK0tEKf=";"XP/IX3+="}for o,J in ipairs({{1;3};{1,1},{2,3}})do while J[1]<J[2]do v[J[1]],v[J[2]],J[1],J[2]=v[J[2]],v[J[1]],J[1]+1,J[2]-1 end end local function J(o)return v[o+45816]end do local o={["/"]=9;["8"]=48;["9"]=1;q=38,o=62;V=33;y=43,d=61,B=50,L=54;v=2;["0"]=21,n=31;p=63;R=5;N=3;i=10;e=35;C=7;l=56;a=47,J=58;m=59;["2"]=36;z=11;M=12;Z=26;O=18;["5"]=20;s=8,["4"]=30,P=55;w=4;U=29;Q=28;r=24,h=41;G=45;c=19;W=34,k=57;T=14,t=44,S=0;f=60;F=42,E=27;u=40;X=25,j=17;["3"]=23,b=13;["1"]=53;Y=32,A=22,K=6,["+"]=16,["6"]=46;["7"]=51;I=37;D=52;H=15,x=49,g=39}local J=type local x=string.sub local d=v local l=string.len local W=string.char local L=table.insert local w=table.concat local h=math.floor for v=1,#d,1 do local X=d[v]if J(X)=="string"then local J=l(X)local H={}local S=1 local k=0 local K=0 while S<=J do local v=x(X,S,S)local d=o[v]if d then k=k+d*64^(3-K)K=K+1 if K==4 then K=0 local o=h(k/65536)local v=h((k%65536)/256)local J=k%256 L(H,W(o,v,J))k=0 end elseif v=="="then L(H,W(h(k/65536)))if S>=J or x(X,S+1,S+1)~="="then L(H,W(h((k%65536)/256)))end break end S=S+1 end d[v]=w(H)end end end local function o(o)test[J(-45815)](o)end function init(v)print(J(-45813))o(J(-45814))end
Defold のビルド処理では、ゲームのリソース(resource)を処理し、Defold エンジンが実行時に使用するのに適した形式へ変換します。テクスチャは Basis Universal 形式にコンパイルされ、コレクション(collection)、ゲームオブジェクト(game object)、コンポーネント(component)は人間が読めるテキスト表現から対応するバイナリ形式に変換されます。Lua ソースコードは処理され、バイトコードにコンパイルされます。音声ファイルなど、その他のアセットはそのまま使用されます。
この処理が完了すると、アセットは1つずつゲームアーカイブに追加されます。ゲームアーカイブは大きなバイナリファイルであり、アーカイブ内の各リソースの位置はアーカイブインデックスファイルに保存されます。この形式はこちらに文書化されています。
Lua ソースファイルは、アーカイブに追加される前に、任意で暗号化することもできます。Defold が既定で提供する暗号化は単純なブロック暗号で、バイナリファイル閲覧ツールでゲームアーカイブを調べたときに、コード内の文字列がすぐに見えることを防ぎます。Defold のソースコードは GitHub で公開されており、暗号鍵もソースコード内に見えるため、暗号学的に安全であるとみなすべきではありません。
リソース暗号化プラグイン(Resource encryption plugin)を実装することで、Lua ソースファイルに独自の暗号化を追加できます。リソース暗号化プラグインは、ビルド処理の一部としてリソースを暗号化するビルド時の部分と、ゲームアーカイブから読み込む際にリソースを復号する実行時の部分で構成されます。独自の暗号化の出発点として使用できる基本的なリソース暗号化プラグインが、GitHub で公開されています。
game.project ファイルは、アプリケーションバンドル(bundle)にそのまま含まれます。公開 API のアクセスキーなど、機密性はあるものの、必ずしも非公開ではない値を保存したい場合があります。このような値のセキュリティを強化するには、game.project に保存する代わりにアプリケーションのバイナリに含めることができます。その場合も、sys.get_config_string() などの Defold API 関数から引き続きアクセスできます。これを行うには、game.project にネイティブ拡張(native extension)を追加し、DM_DECLARE_CONFIGFILE_EXTENSION マクロを使用して、Defold API 関数による設定値の取得を独自の処理で上書きします。出発点として使用できるサンプルプロジェクトが、GitHub で公開されています。
ビデオゲームにおけるチートは、ゲーム業界そのものと同じくらい昔から存在しています。かつては人気のビデオゲーム雑誌でチートコードが紹介され、初期の家庭用コンピューター向けにはチート専用のカートリッジが販売されていました。業界やゲームの進化とともに、チートを行うユーザーとその手法も進化してきました。ゲームでよく使われるチートの仕組みには、次のようなものがあります。
チートを行うユーザーへの対策は難しく、不可能に近いものです。リモートサーバーでゲームを実行し、ユーザーのデバイスに直接ストリーミングするクラウドゲームでさえ、チートを完全に免れることはできません。
Defold はエンジンやツールにチート対策ソリューションを提供しておらず、そのような対策は、ゲーム向けのチート対策ソリューションを専門とする多くの企業に委ねています。
Defold のソケット通信と HTTP 通信は、セキュアなソケット接続をサポートしています。サーバーを認証し、クライアントからサーバー、またはその逆へ転送中のデータのプライバシーと完全性を保護するため、すべてのサーバー通信で安全な接続を使用することを推奨します。Defold は、TLS および SSL プロトコルのオープンソース実装として、広く普及している Mbed TLS を使用しています。Mbed TLS は ARM とその技術パートナーによって開発されています。
ネットワーク通信に対する中間者攻撃を防ぐため、サーバーとの接続を確立する際の SSL ハンドシェイク中に、証明書チェーンを検証できます。これを行うには、Defold のネットワーククライアントに公開鍵のリストを渡します。ネットワーク通信の安全確保について詳しくは、ネットワークマニュアルの SSL 検証に関するセクションを参照してください。
ゲームの作成にサードパーティー製のライブラリやネイティブ拡張を使用する必要はありませんが、開発を速めるために公式の Asset Portal からアセットを利用することは、開発者の間で非常に一般的になっています。Asset Portal には、サードパーティー製 SDK との連携から、画面マネージャー、UI ライブラリ、カメラなどに至るまで、多種多様なアセットが用意されています。
Asset Portal のアセットは、いずれも Defold Foundation によるレビューを受けていません。Asset Portal から取得したアセットの使用によって生じるコンピューターシステムやその他のデバイスへの損害、またはデータの損失について、Defold Foundation は責任を負いません。詳細な条項は利用規約で確認できます。
使用前にアセットをレビューし、プロジェクトでの使用に適していると判断したら、そのアセットのフォークまたはコピーを作成することを推奨します。これにより、気付かないうちにアセットが変更されることを防げます。
Defold のクラウドビルドサーバー(extender サーバーとも呼ばれます)は、エンジン自体の再ビルドを必要とせずに、開発者が Defold エンジンへ新しい機能を追加できるようにするために作られました。ネイティブコードを含む Defold プロジェクトを初めてビルドするとき、そのネイティブコードと関連するリソースがクラウドビルドサーバーへ送信されます。サーバーではカスタム版の Defold エンジンが作成され、開発者へ返送されます。カスタムのアプリケーションマニフェスト(application manifest)を使用してエンジンから未使用のコンポーネントを削除するビルドにも、同じ処理が適用されます。
クラウドビルドサーバーは AWS 上でホストされ、セキュリティのベストプラクティスに従って構築されています。ただし、Defold Foundation は、クラウドビルドサーバーが利用者の要件を満たすこと、欠陥やウイルスがないこと、安全であること、エラーがないこと、またはサーバーの利用が中断されず安全であることを保証しません。詳細な条項は利用規約で確認できます。
ビルドサーバーのセキュリティや可用性が懸念される場合は、独自のプライベートビルドサーバーを構築することを推奨します。独自のサーバーを構築する手順は、GitHub の extender リポジトリにあるメインの README ファイルで確認できます。
Defold の Live Update システムでは、メインのゲームバンドルからコンテンツを除外し、後からダウンロードして使用できます。典型的な用途は、プレイヤーのゲーム進行に合わせて、追加のレベル、マップ、ワールドをダウンロードすることです。
除外したコンテンツをダウンロードしてゲームで使用する準備をする際、エンジンは使用前にそのコンテンツを検証します。この検証では、次の項目を確認します。
この処理について詳しくは、Live Update マニュアルを参照してください。